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(57) Abstract 

TTiere is disclosed a network control system (32) for use in a communication network (12) for ooamffing the receipt anc 
transmission of messages between at least a pair of nodes (18) of the network. Messages conveyed within the network includt 
short messages having a length less than a predetermined number of bytes and long messages having a length greater than tnt 
predetermined number of bytes. The network control system is located at least at one of the nodes and includes a connectionless 
network control portion for controlling the transmission and receipt of the short messages and a connection-onented networt 
control portion coupled to the connectionless network control portion for establishing a connection with the other node for con 
trolling the transmission and receipt of the long messages between the pair of nodes. The connectionless jwrtion of the system in- 
cludes a transport stage which provides end-to-end reliability within the system, a network stage for establishing routing of the 
messages, and a data link stage for providing point-to-point reliability and other control functions such as message flow control, 
node ^synchronization, and node suspension. The connection-oriented portion of the system includes a session stage for han 
dling the communication of long messages greater than the predetermined number of bytes m length. 
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NETWORK CONTROL SYSTEM AND METHOD 



BACKGROUND OF THE INVENTION 



The present invention is directed to an 
improved network control system and method for use in 
a communication network of the type including a 
plurality of nodes coupled to a bi-directional bus. 
5 The network control system and method is arranged to 

control the receipt and transmission of messages and 
provide control and supervisory functions at one of 
the network nodes. In a preferred network, each node 
is associated with a network control system of the 
10 present invention which correspondingly implements the 

method of the present invention. 

There is a need in the art for a 
connectionless network control system which is 
distributed in its architecture to correspond to the 
15 distributed configuration of a control system, such as 

a facility management system. The present invention 
provides such a network control system and method 
which is distributed in architecture and which 
provides high reliability. The present invention 
2 0 further provides such a network control system which 

includes a connection-oriented network control portion 
for use in controlling the transmission and receipt of 
messages containing a large amount of information 
between one point in the network and another. 
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SUMMARY OF THE INVENTION 



The invention therefore provides a network 
control system and method for use in a communication 

3 0 network of the type including a first plurality of 

nodes coupled to a first link of a bi-directional bus 
for controlling the transmission and reception of 
messages at one node of the first plurality of nodes, 
wherein the network control system is coupled between 

3 5 a plurality of application modules and the first link 
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of the bi-directional bus, and wherein each 
application module has a unique address and at least 
some of the application modules are arranged to 
originate a message and to provide therewith the 
address for which the originated messages is destined. 
The network control system includes a transport stage 
coupled to each of the application modules for 
conveying messages received at the one node and 
destined for the application modules at the one node 
to the application modules and receiving messages 
originating at the one node by the application 
modules. The network control system further includes 
a network stage coupled to the transport stage for 
conveying the messages received at the one node and 
destined for the application modules at the one node 
to the transport stage and for receiving from the 
transport stage messages originated by the application 
modules at the one node. The network stage is 
responsive to the destination addresses of the 
messages to be transmitted from the one node for 
establishing the routing of the messages to be 
transmitted from the one node. The network control 
system further includes a data link stage coupled 
between the network stage and the first link of the 
bus for conveying messages received at the one node to 
the network stage and for receiving from the network 
stage messages to be transmitted from the one node on 
the first link of the bus. 



a control system and method wherein the network 
includes a second link of the bi-directional bus, a 
- bridging node coupling the first link to the second 
link, and a second plurality of nodes coupled to the 
second link and wherein the transport stage includes 
confirmation means for confirming receipt of messages 
between the one node and any one of the second 
plurality of nodes. 



The present invention further provides such 
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The present invention further provides such 
a network control system and method wherein the 
network is arranged for synchronous transmission and 
reception of messages between the nodes and wherein 
the data link stage includes reset means for 
resynchronizing the one node with any one of the other 
nodes when the one node is not in synchronism with any 
one of the other nodes. 

The present invention still further provides 
such a network control system and method wherein the 
data link stage includes limiting means for limiting 
the number of received messages that the one node can 
process at any one time. 

The present invention still further provides 
such a network control system and method wherein the 
data link stage includes suspend means responsive to 
a suspend request message for suspending the one node 
to preclude the one node from transmitting messages 
onto the bus. 

The present invention further provides such 
a network control system and method wherein the 
network is capable of carrying messages having a 
length of up to a predetermined number of bytes and 
wherein the system further includes a 
connection-oriented session stage coupled between the 
application modules and the transport stage of the one 
node for providing a session service including 
dividing a long message having a length greater than 
the predetermined number of bytes into message parts 
having lengths less than a predetermined number of 
bytes and for conveying the message parts in sequence 
to the transport stage. 

The present invention also provides a 
network control system for use in a communication 
network for controlling the receipt and transmission 
of messages between at least a pair of nodes of the 
network, wherein the messages include short messages 
having a length less than a predetermined number of 
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bytes and long messages having a length greater than 
the predetermined number of bytes and wherein the 
network control system is located at least at one of 
the nodes. The network control system includes a 
connectionless network control portion for controlling 
the receipt and transmission of the short messages and 
a connection-oriented network control portion coupled 
to the connectionless network control portion for 
establishing a connection with the other node for 
controlling the transmission and receipt of the long 
messages between the pair of nodes. 



a session handling system for use in a communication 
network including a plurality of nodes distributed on 
a bi-directional bus for conveying messages between 
the nodes, wherein the messages on the bus are limited 
to a given length, and wherein the session system 
provides a session service including dividing long 
messages greater in length than the given length into 
message parts having a length less than the given 
length for transmission on the bus. The session 
system includes a session stage at least at a pair of 
the nodes, each session stage being arranged for 
initiating a session connection with the other session 
stage for transmitting a . plurality of message parts 
from its node to the other session stage of the other 
node. Each session stage includes means for 

determining which of the pair of nodes is a priority 
node in response to each session stage simultaneously 
initiating a session connection with the other session 
stage to thereby permit completion of the session by 
the priority node first, and each session stage 
further including session connection maintaining means 
for enabling the completion of the non-priority node 
session immediately after the completion of the 
P r i°rity node session and before the session 
connection is terminated. 



The present invention still further provides 
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network control system, for use in a communication 
network including a plurality of nodes distributed on 
a bi-directional bus f for controlling the reception 
and transmission of messages at one node of the 
plurality of nodes. The network control system is 
coupled between a plurality of application modules and 
a transmit/receive module which is in turn coupled to 
the bi-directional bus. Each application module has 
a unique address and at least some of the application 
modules are arranged to originate a message and to 
provide therewith the address for which the originated 
message is destined and a memory location address. 
The network control system includes a buffer pool for 
storing messages to be transmitted from the one node 
at memory locations corresponding to the memory 
location addresses, a data link stage coupled to the 
application modules for receiving the memory location 
address of a message to be transmitted from the one 
node, and a timer manager including timing means for 
timing a time period up to a predetermined time period 
after the message to be transmitted is transmitted. 
The transmit/receive module is coupled to the data 
link stage for receiving the memory location address 
of the message to be transmitted, coupled to the 
buffer pool for obtaining the message to be 
transmitted for transmitting the message onto the bus, 
and coupled to the timer manager for starting the 
timing means responsive to transmitting the message 
onto the bus. 



a timer manager for use in a network control system of 
one node of a connectionless communication network, 
the communication network being of the type including 
a plurality of nodes distributed on a bi-directional 
bus for conveying messages between the nodes, and 
wherein the network control system includes a buffer 
pool for storing messages to be transmitted from the 



The present invention still further provides 



one node and a data link stage for receiving the 
buffer pool storage address of a message to 
transmitted from the one node and causing the message 
to be transmitted from the one node and causing the 
message to be accessed and transmitted onto the bus. 
The timer manager is coupled to the buffer pool and to 
the data link stage and includes means for accessing 
the buffer pool for establishing a table including a 
plurality of entry slots, each slot having an 
associated timer entry index and being arranged for 
storing the buffer pool storage address of a message 
to be transmitted from the one node, means responsive 
to an add timer request from the data link stage for 
locating an available entry slot in the table tor a 
message to be transmitted, and means for obtaining the 
buffer pool storage address of the message from the 
data link stage. The time manager further includes 
means for storing the buffer pool storage address in 
the entry slot, means for conveying to the data link 
stage the index of the entry slot, timing means 
associated with the entry slot, and starting means for 
starting the timing means responsive to the message 
being transmitted onto the bus. 

RRTEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic representation of a 
communication network which may embody the present 
invention to advantage; 

Figure 2 is a block diagram of a 
representative node of the communication network 
illustrated in Figure I; 

Figure 3 is a block diagram of a network 
control system embodying the present invention and 
which is capable of correspondingly implementing the 
method of the present invention; 

Figures 4 through 2 0 are flow diagrams 
illustrating the manner in which the data link stage 
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illustrated in Figure .3 may be implemented in 
accordance with the present invention; 

Figure 21 is a flow diagram illustrating the 
manner in which the network stage of Figure 3 may be 
5 implemented in accordance with the present invention 

to process a received message transferred to it by the 

data link stage; 

Figure 22 is a flow diagram illustrating the 

manner in which the network stage may be implemented 
10 in accordance with the present invention to process a 

message to be transmitted onto the bus which it 

receives from the transport stage of Figure 3 ; 

Figures 23 through 33 are flow diagrams 

illustrating the manner in which the transport stage 
!5 0 f Figure 3 may be implemented in accordance with the 

present invention; 

Figures 34 through 41 are flow diagrams 

illustrating the manner in which the session stage of 

Figure 3 may be implemented in accordance with the 
20 present invention to initiate a connect request 

responsive to receiving a long message from an 

application module; 

Figures 42 through 50 are flow diagrams 

illustrating the manner in which the timer manager may 
25 be implemented in accordance with the present 

invention. 

DESCRIPTION OF THE PREFERRED EMBODIMENT 
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Referring now to Figure 1, it illustrates a 
communication network 10 which may embody the present 
invention- The network 10 includes a bi-directional 
bus 12 which is divided into a first link 14 and a 
second link 16. The network 10 further includes a 
first plurality of nodes 18 , 20 r and 22 associated 
with the first link 14 and a second plurality of nodes 
24, 26, and 28 associated with the second link 16. 
The coiamunication network 10 further includes a 
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bridging node 3 0 which couples the first link 14 and 
the second link 16. 

Each of the first plurality of nodes 18 , 2 0 
and 2 2 includes a network control system 32, 34 and 3 6 
respectively which preferably correspond to the 
network control system of the present invention. In 
addition, each of the first plurality of nodes 18, 20 
and 22 includes at least one application module 
coupled to its respective network control systems. To 
that end, node 18 includes application modules 38a, 
38b and 38c coupled to network control system 32, node 
20 includes an application module 40 coupled to 
network control system 34, and node 22 includes 
application modules 42a and 42b coupled to network 
control system 36. Each of the network control 
systems 32, 34 and 36 is coupled to the first link 14 
of the bi-directional bus 12. As will be seen 
hereinafter with respect to Figure 3 , the network 
control systems 32, 34 and 3 6 are coupled to the first 
link 14 through a transmit/ receive module. 

The second plurality of nodes 24, 26 and 28 
similarly include network control systems 44, 46 and 
48 which, again, preferably correspond to the network 
control system of the present invention. Node 24 
includes application modules 50a and 50b coupled to 
network control system 44, node 26 includes 
application modules 52a and 52b coupled to network 
control system 46 and node 2 8 includes application 
module 54 coupled to network control system 48. The 
network control systems 44, 46 and 48 of the second 
plurality of nodes are coupled to the second link 16 
through a transmit/ receive module as illustrated in 
Figure 3 . 

The bus 12 is illustrated as being divided 
into the first link 14 and the second link 16 to 
illustrate that a limited number of nodes may be 
coupled to a bus. When the number of nodes exceeds 
the number of nodes which may be coupled to a bus, it 
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is necessary to subdivide the bus into links as 
illustrated and to couple the links together with 
bridging nodes, such as bridging node 30. Bridging 
node 3 0 could be either a bridge or a gateway, A 
bridge is a bridging node which couples two links 
together which utilize the same network protocol. A 
gateway is a bridging node which couples two links 
together wherein the network protocol of one link is 
different from the network protocol of the other link. 
Such bridges and gateways are well known in the art. 

The communication network 10 utilizes a 
protocol known in the art as a sliding window 
protocol. Each of the nodes of the communication 
network include a window which contains 16 frames 
numbered 0 through 15, each frame of which 
corresponding to a separate message. The protocol 
requires that, when any one of the nodes is 
communicating with any other node, the two nodes be 
synchronized together to permit proper reception of a 
message. Such synchronization requires that the 
transmitting node maintain a list of consecutive 
sequence numbers corresponding to the frames. It is 
permitted to send messages in the "sender's window". 
The receiving node similarly maintains a list of 
consecutive sequence numbers corresponding to the 
frames it is permitted to accept in the "receiver's 
window" , 

The sliding window protocol also limits the 
number of unacknowledged messages that any one node 
can transmit at one time to a predetermined number of 
messages. In accordance with this preferred 

embodiment, the number of unacknowledged messages 
which may be transmitted from any one node is eight. 
Also, the communication network 10 is arranged so that 
only one node can be transmitting messages out onto 
the bus at any one time. Each node takes its turn in 
transmitting messages. This precludes the possibility 
of two messages being sent out on the bus 12 in 
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opposite directions and the potential interference 
which may be caused to each message by the other. 

Each window contains 16 frames numbered 0 
through 15 with each frame corresponding to a separate 
message. Each frame includes a header comprising a 
number of boxes which are arranged to contain 
information which coordinates the transmission and 
receipt of the messages and which, as will be seen in 
conjunction with Figure 3 and the flow diagrams of 
Figures 4 through 50, are used to denote particular 
services to be provided to the messages by the various 
stages of the network control system. 

The first box is for the address of the 
source which originated the message and includes the 
link, the node and the application module or network 
control system stage which originated the message. 
The second box is for the address of the application 
module or control system stage for which the message 
is ultimately destined and includes the link, the node 
and the application module or the network control 
system stage to ultimately receive the message. The 
third box is for the address of an intermediary 
source. If a message is to be sent from one link to 
another link, the message is actually conveyed in hops 
through intermediary nodes. The intermediary source 
address will contain the link, the node and the data 
link stage of the intermediary source node. The 
fourth box is for the address of an intermediary 
destination node of the message. This address also 
includes the link, node and data link stage of the 
intermediary node. If a message is transmitted 
- between nodes on the same link, the source and 
destination addresses are duplicated by convention to 
avoid confusion within the network. 

As will be seen hereinafter, the network 
control system of the present invention includes a 
session stage, a transport stage, a network stage, and 
a data link stage. As a message to be transmitted is 



11 

processed through the various network control system 
stages, each stage of the system fills in its own 
header information into various boxes provided in the 
header. These stages will set a bit in the message 
header if they are required to provide a service to 

the message. 

There are three different types of messages 
which are conveyed from one point to another within 
the communication network 10. These message types are 
control messages or frames, supervisory messages or 
frames, and data messages or frames. A box is also 
provided in each frame header for indicating the type 
of message being conveyed. 

The header in each frame or message is 
relatively short and comprises on the order of 4 
bytes. If the bus 12 is an ARCNET bus, each message 
may contain up to 512 bytes of information. As a 
result, 508 bytes of the message are allocated to the 
message itself, with 4 bytes being allocated for the 
header. As will be referred to hereinafter, the 
communication network 10 is arranged for conveying 
short messages of less than 508 bytes. However, 
messages having a length greater than 508 bytes may 
also be conveyed from one point to another within the 
communication network 10 through the use of a 
connection-oriented session stage. 

Referring now to Figure 2 , it illustrates in 
block diagram form the configuration that a node, such 
as node 18, may take when the network control system 
of the present invention is embodied in a facility 
management system for controlling the internal 
environment of a portion of an office building, for 
example. As illustrated, the node or control system 
18 is coupled to the link 14 of the bi-directional 
bus. The control system includes a network control 
module 60 which includes the network control system 32 
and the application modules 38a, 38b and 38c. The 
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control system further includes a digital control 
module 62 coupled to the network control module 60. 

The main function of the network control 
module 60 is to communicate with other network control 
modules of the system on an equal basis as a peer in 
accordance with the protocol established by the 
network control system 3 2 and to control its 
associated digital control module 62 under its own 
assigned protocol through the application modules 38a, 
3 8b and 3 8c. Such a protocol may include setting 
temperature control setpoints, heating schedules, 
lighting schedules, etc. The network control module, 
in accordance with its protocol, sends high-level 
commands through its application modules to the 
digital control module which then executes on those 
commands by performing closed-loop operations by 
issuing a suitable digital or analog control signal at 
its outputs responsive to sensed input conditions at 
its inputs provided by remote sensors. Hence, the 
digital control module performs decision-making 
processes, gathers information from its remote 
sensors, digitizes the information, and executes 
control functions to satisfy the high-level commands 
of the network control module. 

The digital control module 62 may include 10 
input channels designated CHI through CH10 . These 
input channels receive various different kinds of 
information from remote sensors which provide 
information of various types indicative of the 
conditions being sensed. The digital control module 
further includes 10 output channels designated OCH1 
through OCH10. From these output channels, the 
digital control module issues control signals which 
are utilized to turn on heaters , start fan motors, or 
adjust dampers, for example. The digital control 
module may perform up to 10 closed-loop control 
functions . 
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One such closed-loop control operation is 
illustrated in Figure 2 in connection with the 10th 
output channel, OCH10, and the 10th input channel, 
CH10. The input channel CH10 is coupled to a remote 
temperature sensor 64, through a terminal block 66 and 
a universal analog input circuit (IAU) 68. The output 
channel OCH10 is coupled to a heater 70 through a 
relay output function module 72 and a terminal block 
74. When the relay of the output function module 72 
closes, the heater 3 2 is turned on for heating an 
internal space such as a room of a building. 

The temperature of the room is sensed by the 
remote sensor 64 which provides, through the terminal 
block 66 and the IAU 68, information in the form of a 
15 resistance having a magnitude indicative of the 

temperature being sensed. When the remote sensor 64 
indicates that the room being heated is at a desired 
temperature dictated by the high-level command of the 
network control module, the digital control module 62 

2 0 will open the relay of the output function module 72 

to turn off the heater 70- When the room temperature 
falls below the desired temperature, the digital 
control module will close the relay of the output 
function module 72 to once again turn on heater 70. 
25 As can be appreciated from the foregoing, 

information must be conveyed from one point to another 
in a facility management system to assure proper 
control of the internal environment of a building. 
Data messages must be sent between an application 

3 0 module of one node to an application module of another 

node. In addition, control and supervisory messages 
must be conveyed between nodes to maintain proper 
control of the communication system. Control messages 
may take the form of reset, suspend, restart, resume, 
35 and reject messages. Supervisory messages may be 

response messages such as acknowledgements to 
acknowledge receipt of messages to provide point-to- 
point and end-to-end reliability. 
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Referring now to Figure 3, it illustrates, 
in block diagram form, a network control system such 
as network control system 3 2 of Figures 1 and 2 
embodying the present invention. The network control 
system 32 is coupled to the first link 14 of the bus 
by a transmit/ receive module 80 and to the plurality 
of application modules 38a, 38b and 38c. The network 
control system 3 2 generally includes a data link stage 
82, a network stage 84, a transport stage 86, a 
session stage 88, a timer manager 90, and a buffer 
pool 92. The data link stage 82, the network stage 
84, the transport stage 86, and the session stage 88 
each includes its own internal storage 82a, 84a, 86a 
and 88a respectively, for storing information which is 
unique to the processes performed within the stages. 

The buffer pool 9 2 is utilized for storing 
data messages to be transmitted onto the bus and 
certain data messages received from the bus. The 
buffer pool 92 also includes a dedicated portion which 
is utilized by the timer manager 90 for maintaining an 
accurate account of the data messages to be 
transmitted. Each data message originated by the 
application modules is stored in the buffer pool 92 at 
an address location designated by the application 
modules in the message headers. Only the address of 
the message is passed from stage to stage within the 
network control system. Ultimately, the header is 
received at the data link stage which provides the 
buffer pool address to the timer manager. The timer 
manager uses its dedicated portion of the buffer pool 
to set up a table including a plurality of entries. 
It will locate an available entry and store the buffer 
pool address of the message in the table and provide 
the various stages with the index of the entry. The 
stages then store the index in their own storage. 
Whenever a stage thus requires the message buffer pool 
address, it will send its index to the timer manager 
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and receive from the timer manager the buffer pool 
address of the message. As a result, to conserve 
memory, the buffer pool provides a single location 
wherein messages are stored. 

Each of the various stages of the system is 
arranged to provide services to those stages which 
precede it and provides its own unique service or 
services within the system. Hence, there is no 
duplication of services within the system. 

The transport stage 86 is arranged to 
receive message headers for messages to be transmitted 
either directly from the application modules or 
through the session stage 88. The application 
modules, when originating a message, use the resources 
15 of the shared buffer pool and provide the headers with 

their address as the source address and the address of 
the destined node. The application modules are the 
generators of all data messages and only originate and 
receive data messages. 

The transport stage 86 is arranged to 
provide end-to-end reliability for messages conveyed 
from its link to a different link. In providing the 
end-to-end confirmation, the transport stage utilizes 
its storage 86a for storing the entry index provided 
by the timer manager and sets a bit in the header 
indicating that the message requires end-to-end 
confirmation and to notify the timer manager to set a 
transport time period during which it expects to 
receive an acknowledgement from the receiving node on 
another link. If the transport stage does not receive 
an acknowledgement within a transport time-out period, 
it will notify the originating application module that 
the message failed to reach the destined node. If 
however, the transport stage receives an 
35 acknowledgement within the transport time-out period, 

it will cause the timer manager to delete its timer 
associated with the message. The transport stage 86 
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is also arranged to format acknowledgements for the 
transport stages on other links as well* 

The transport stage also conveys the buffer 
pool address of a received message to the application 
5 modules. The transport stage receives the address 

from the network stage and causes the appropriate 
module to obtain its received message from the buffer 
pool . 

The transport stage also time-stamps the 
10 headers of messages to be transmitted with two time- 

stamps. The first is the time-stamp of the last 
message transmitted to the destined node (the old 
time- stamp) . The second time-stamp is the time-stamp 
of the current message (the new time-stamp) . The 
15 time-stamps are used by the receiving transport stage 

to determine if a message has been received out of 
order and hence, if a prior message was lost. 

The network stage 84 provides routing for 
the messages which are transmitted from its node. The 

2 0 network stage 84 includes a routing table within its 

internal storage 84a to determine the address of the 
node to which a message must be sent in order for that 
message to reach its final destination. The routing 
table consists of a directory or routing table wherein 
25 each node in the network is listed in an entry along 

with a corresponding address to which a message must 
be sent to enable the message to reach its final 
destination. If a message is to be sent to a node on 
the same link, the network stage 84 will use its 

3 0 routing table to duplicate the destination addresses 

an intermediary address in the header. If the message 
is destined for a node on another link, the network 
stage will use its routing table to provide the header 
with an intermediary node address different than the 
3 5 destination address in the header. For messages 

originated at its node, the network stage will provide 
in the space of the header allotted for the 
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intermediary source, the source address of its 
application module which originated the message. 

If the message to be transmitted from the 
node 18 is a message originated at another node and 
5 - destined for a node on its link, the network stage 

will use its routing table to provide the header with 
the final dstination address in the intermediary node 
address poriton of the ehad and its address in the 
intermediary source portion of the header. If the 

10 message is received from another node and is destined 

for a node in another link, the network stage will use 
its routing table to provide the header with the 
intermediary address of the next node to receive the 
message and will provide its address in the 

15 intermediary node source portion of the header. 

In providing the addresses as discussed 
above, the network stage 84 utilizes its routing table 
within the storage 84a to determine to which node the 
i message ought to be sent in response to the 

► 2 0 destination address in the header of the message. The 

network stage storage 84a may also include alternative 
routing information to permit the network stage 84 to 
select an alternate routing path should an alternate 
routing path be necessary. The routing table within 
the network storage 84a is preferably a dynamic table 
which is constantly being updated due to the fact that 
certain nodes including bridging nodes of the network 
may be brought on-line or off -line at any time. 

The network stage also conveys to the 

3 0 transport stage the message addresses of messages 

received from other nodes which are destined for 
application modules of its node. The network stage 
receives those message addresses from the data link 
stage 82. As previously mentioned, the buffer pool 

35 addresses for those messages are conveyed to the 

application modules which then obtain the messages 
from the buffer pool. 
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Even though the physical link is a broadcast 
media wherein all messages may be heard by every node 
on the same link, since only one node is addressed in 
the message header, only that one node will receive 
and process the message. This fact, together with the 
routing table of the network stage, serves to 
establish logical virtual circuit connections within 
the network. One form of transmission, referred to 
herein as a broadcast transmission, permits a node to 
send a message to more than one node at any one time 
and will be described herein with respect to the flow 
diagrams . 

The data link stage 82 provides a number of 
different functions within the network control system 
32 which provide for the basic reliability of the 
network control system 32. The data link stage 82, 
for example, assures that its node is in synchronism 
with another node with which its node is attempting to 
communicate. The data link stage 82 will retransmit 
messages sent from its node a given number of times in 
the absence of an acknowledgement and if the message 
is retransmitted a given number of times without an 
acknowledgement, the data link stage 82 will format a 
reset message to the destined node for the purpose of 
resynchronizing its node with the destined node. The 
reset message is a control message sent without a 
frame number. When the other node receives the reset 
message, the two nodes will reset their control tables 
to corresponding receiving and sending windows. 
During the reset process, the data link stage 82 will 
preclude the messages to be transmitted which are 
stored in the buffer pool 92 from being cleared and 
suspend the transmission of all messages from its node 
except for the reset messages. 

The data link stage 82 also provides for 
limiting the number of received messages that its node 
can process at any one time. When the number of 
received data messages stored in the buffer pool 
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equals a maximum number of stored received messages, 
the data link stage 82 will reduce the message flow to 
its node. The data link stage will permit its node to 
process control messages and supervisory messages , but 
will not receive data messages from other nodes unless 
the data messages are of critical priority 

The data link stage 82 also provides for the 
suspension of its node responsive to receiving a 
suspend request message. If the data link stage 82 
receives a suspend request message, it suspends its 
node by precluding its node from transmitting messages 

onto the bus. 

The data link stage 82 also provides for the 
restarting of a node in response to a restart request 

15 after the node has been suspended. In restarting its 

node, the data link stage 82 sends a reset message to 
all of the nodes with which it has communicated to 
thereby cause those nodes to be resynchronized with 
the node being restarted. 

20 The data link stage 82 further provides for 

point-to-point reliability in the network. Point-to- 
point reliability or confirmation of receipt of 
messages occurs for messages sent between nodes which 
are coupled to the same link of the communication bus. 

25 The data link stage formats acknowledgement messages 

to acknowledge receipt of data messages and control 
messages. Supervisory messages such as 

acknowledgements are not acknowledged. 

Hence, the data link stage 82 is arranged 

3 0 for both transmitting acknowledgement messages to 

acknowledge receipt of received messages and for 
retransmitting messages which are not acknowledged as 
received by a receiving node. In this manner, point- 
to-point reliability is provided within the 

35 communication network utilizing the network control 

system of the present invention. 

As previously mentioned, each frame or 
message is limited to a given length of 512 bytes 
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comprising 508 bytes of message information and four 
bytes of header information. To enable messages 
longer than 512 bytes to be transmitted from one node 
to another, the session stage 88 provides a session 
service for long messages greater than the given 
length of 512 bytes. The session stage 88 is the 
connection-oriented portion of the network control 
system. Before providing its session services, the 
session stage sets up a session connection with the 
session stage of the receiving node with which it is 
to communicate. 

The session stage is a connection-oriented 
portion of the network control system. It establishes 
a connection between itself and the session stage of 
the receiving node. It breaks the long message up 
into message parts and has the message parts 
transmitted onto the bus. The session stage 88 is 
also capable of maintaing more than one session at any 
ont time. 

The timer manager 90 is utilized in the 
system for keeping track of the location of the 
messages to be transmitted from its node. As 
previously mentioned, the timer manager 90 maintains 
a dedicated portion of the buffer pool 9 2 wherein it 
maintains a table containing a plurality of entries 
with each entry including buffer pool storage address 
of a message and an entry index. The timer manager 
provides various stages of the network control system 
with its entry index for its messages so that only the 
timer manager need keep track of the buffer pool 
storage addresses of the messages to be transmitted. 
The timer manager also provides timers for timing 
messages after they have been transmitted. When a 
message requires both a transport timer and a data 
link timer, the transport timer will be requested 
first and the timer manager will use that timer for 
the data link service also. Only the timer manager 
need keep track of the condition of its timers. 
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The timer manager 90 is also responsive to 
address requests from the data link stage, transport 
stage or the session stage. For example, if a data 
link timer times out, the data link stage will request 
the address for the message associated with the timed 
out timer from the timer manager which then conveys 
the buffer pool storage address of the message to the 
data link stage- This enables the data link stage to 
retransmit the message should that be necessary or 

appropriate . 

Now that a general description of the 
network control system 32 of Figure 3 has been 
provided, further details of the implementation of the 
network control system can be obtained by making 
reference to the following description taken in 
conjunction with the detailed flow diagrams of Figures 
4 through 50. 

DATA LINK STAGE 

Figures 4 through 20 are flow diagrams 
illustrating the manner in which the data link stage 
may be implemented in accordance. Referring now to 
Figure 4, it illustrates the manner in which the data 
link stage categorizes a received message. 

When the data link stage receives a message 
in accordance with step 100, it has received the 
message address for a message which is to be 
transmitted or has been received from another node. 
Control and data messages to be transmitted are stored 
in the buffer pool and data messages received from 
other nodes are stored in the buffer pool. Received 
control and supervisory messages are not stored in the 
buffer pool because these messages are processed 
internally within the network control system. From 
the received message address, the data link stage 
first determines whether the message is destined for 
another node in step 102. If the message is destined 
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for another node, the data link stage will then 
proceed to transmit the message as will be described 
with respect to Figure 5. If the message is not 
destined for another node, in step 104, the data link 
stage then determines whether the message is from the 
timer manager. If the message is from the timer 
manager, the message must be an expired time-out 
message which the data link stage processes in 
accordance with the flow diagram of Figure 8 to be 
described hereinafter. If the message is not from the 
timer manager, the data link stage then determines in 
step 106 if the message is from another node. If the 
message is from another node, the message is 
considered to be a received message which the data 
link stage processes in accordance with Figure 9 to be 
described hereinafter. If the message is not destined 
for another node, is not a message from the timer 
manager, or is not from another node, the data link 
stage reverts to an error handling routine 108. After 
the error handling routine 108, the data link stage 
exits and is conditioned for receiving another message 
according to step 100. 

Referring now to Figure 5, it illustrates 
the manner in which the data link stage may be 
implemented to transmit a message after determining in 
step 102 that a received message is destined for 
another node. In step 110, the message to transmit is 
received by this portion of the data link stage. The 
data link stage first determines in step 112 whether 
the message is a response message or frame. If the 
message is a response message, it conveys the response 
message to the transmit module 80 in accordance with 
step 114. The response message may be, for example, 
an acknowledgement message originated by one of the 
other stages of the network control system. After 
sending the response message to the transmit module, 
the data link stage exits and returns to receive 
another message to transmit in accordance with step 
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110. If in step 112, the data link stage determines 
that the message is not a response frame it will then, 
in step 116, determine if the message is a control 
message. Such a control frame may be a reject 
message, a reset message, or a resume message. If the 
message is a control message, the data link stage then 
moves to a transmit pre-process routine to be 
described hereinafter with respect to Figure 6. If 
the message is not a control frame, the data link 
stage then determines in step 118 if it is under a 
restriction to send to the destined node only high 
priority messages. In other words, the data link 
stage determines whether it has received from that 
node a reject message. If the data link stage had 
15 received a reject message from the node to which the 

message is to be transmitted, the data link stage 
would have entered the address of that node in its 
storage 82a to enable the data link stage to make the 
determination according to step 118. If the data link 
20 stage is not under a restriction to send only high 

priority messages, it will enter the transmit pre- 
process which will be described hereinafter with 
respect to Figure 6. If however, the data link stage 
determines that it is under such a restriction, then 
25 it will determine in accordance with step 120 whether 

the message is critical. If the message is critical, 
it will enter into the transmit pre-process. A 
message may be considered critical if it is a data 
message with regard to safety related factors such as 
3 0 a fire or security alarm, for example. If the message 

is not critical, then, in accordance with step 122, 
the data link stage will determine if the message was 
originated locally within its own node. If the 
message was originated within in its own node, the 
3 5 data link stage then, in accordance with step 124, 

will notify the local application module which 
originated the message that the message could not be 
transmitted. Thereafter, the data link stage exits to 



24 

receive another message to transmit in accordance with 
step 110. If, however, the message was originated 
from another node, the data link stage will simply 
discard the message in accordance with step 126 and 
then exit. 

Referring now to Figure 6, it illustrates 
the manner in which the data link stage may be" 
implemented to pre-process a message to be 
transmitted. This portion of the data link stage 
receives the message to be pre-processed in accordance 
with step 130. The data link stage first determines 
whether its node is suspended in accordance with step 
132. If its node is suspended, it will discard the 
message in step 134 and then notify the local task or 
application module in step 136 that it was unable to 
transmit the message. The data link stage then exits 
to receive another message to pre-process before 

tr ansmi s s i on . 

If, in step 132, the data link^ stage 
determines that its node is not suspended, then in 
step 13 8, the data link stage determines whether the 
message or frame is a new transmission. If the 
message is not a new transmission, then the data link 
stage will treat the message as one to be 
retransmitted and will enter a retransmit process as 
will be described hereinafter with respect to Figure 
7. If however, the data link stage determines that 
the message is a new transmission, the data link stage 
will then determine in step 140 if the message is a 
multi-cast message. If the message is a broadcast 
message, which the data link stage determines from the 
destination address which will indicate that the 
message is to be sent to a plurality of nodes 
simultaneously, the data link stage will then, in 
accordance with step 142, convey the message frame to 
the transmit/ receive module for transmission of the 
message onto the bus and then the data link stage will 
exit. 
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If the data link stage determines in step 
14 0 that the message is not a broadcast message, it 
will then determine whether its transmit window is 
full in accordance with step 144. This is where the 
sliding window protocol limits the number of messages 
that a node can transmit at any one time. Each node 
is limited to transmitting eight unacknowledged 
messages. If this node has already transmitted eight 
messages which are not acknowledged, then the data 
link stage determines that the transmit window is full 
and will delay its buffer pool in step 146 so that the 
message is not conveyed from the buffer pool to the 
transmit/receive module. The data link stage then 
exits. 

If the data link stage determines that the 
transmit window is not full, the data link stage then 
determines in step 148 if the message is a control 
frame. If the message is not a control frame, the 
data link stage will then, in step 150, tag the 
message and update its table within its storage 82a to 
provide an entry for the entry index to be received 
from the timer manager. 

After updating its table, or if the message 
is a control frame, the data link stage then in step 
152 inserts into the message header the appropriate 
bit to indicate what type of message is to be 
transmitted. If it is a control message, it will be 
given a higher priority than if it is a data message. 
After marking the message with its priority in step 
152, the data link stage then determines in step 154 
if an end-to-end service is to be provided to this 
message by the transport stage. The data link stage 
makes this determination from information contained in 
the header for the message. If an end-to-end service 
is to be provided to the message, the transport stage 
will have already requested that the timer manager add 
a timer for the end-to-end service. As a result, in 
step 156, the data link stage will use the timer 



WO 91/11871 ^ 26 ^ PCT/US91/00257 

manager timer associated with the end-to-end service 
for providing its point-to-point service. In step 
158, the data link stage then stores the timer manager 
entry index for the associated timer in its storage 
82a and then proceeds to step 142 to send the message 
address to the transmit/ receive module 80. 

If an end-to-end service is not to be 
provided to the message as determined in step 154 , the 
data link stage then in step 160 requests an 
associated timer for the message from the timer 
manager. The timer manager after locating an 
available entry in its table, provides the data link 
stage with the entry index for the timer which the 
data link stage then stores in its storage in step 
158. The data link stage then proceeds to step 142 to 
send the message address to the transmit/ receive 
module . 

Referring now to Figure 7, it illustrates 
the manner in which the data link stage may be 
implemented to cause a message to be retransmitted. 
This portion of the data link stage receives the 
message to be retransmitted in step 162 and then 
determines in step 164 if the retransmission count for 
this message has reached the maximum number of 
retransmissions. In accordance with this preferred 
embodiment, the maximum number of retransmission is 
five retransmissions. 

If the retransmission count has not reached 
the maximum number of retransmissions, the data link 
stage then in step 166 logs the retransmission count 
and then in step 168 uses the timer already associated 
with the message for the retransmission. The data 
link stage then increments the retransmission count 
and then in step 172 sends the message address to the 
transmit/receive module for retransmission and then 
exits . 

If the retransmission count has reached the 
maximum number of retransmissions, the data link stage 
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will then log the retransmission failure in its table 
in step 174 and then in step 176 determines whether 
the retransmission failure was the result of a 
retransmitted reset message. If the retransmitted 
5 message was not a reset message, the data link stage 

then in step 178 marks that the reset process is in 
progress and in step 180, stops all timers for all 
outstanding messages for the destined node. In 
stopping all of these timers, the data link stage 

10 assures that the messages to be transmitted to the 

destined node are not cleared from the buffer pool 92. 

The data link stage in step 182 formats a 
reset message for the destined node and then 
associates the original timer associated with the 

15 original retransmitted message with the reset message 

in step 184. The data link stage then proceeds in 
step 172 to send the reset message to the 
transmit/ receive module 80 which immediately places 
the message onto the bus. 

20 If in step 176, the data link stage 

determines that the retransmission failure was the 
result of a retransmitted reset message, it will enter 
a clean-up routine for the purpose of re-initializing 
the destination table for the failed node. To that 

25 end, the data link stage in step 186 determines 

whether there are any outstanding messages which are 
still stored in the buffer pool which have not yet 
been transmitted onto the bus. If there are such 
outstanding messages stored in the buffer pool, the 

30 data link stage then in step 188 will unbuffer and 

discard the message. In step 190, it will then notify 
its local task or application module originating the 
message that the message was not transmitted. In step 
192, it will request the timer manager to delete the 

35 timer which was associated with the outstanding 

message. Then in step 194, the data link stage 
determines whether all of the outstanding messages 
have been unbuffered. If not, the data link stage 
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returns to step 188 to continue the process. In this 
manner, the data link stage clears the outstanding 
messages in the buffer pool 92 one at a time until all 
of the outstanding messages for the specified node are 
5 cleared from the buffer pool. 

If all of the messages to be transmitted are 
cleared from the buffer pool, or if there are no 
outstanding messages which are still stored which have 
not yet been transmitted, the data link stage then in 

10 step 196 determines whether there are any stored 

messages in the buffer pool which it has received from 
other nodes out of order. The network is configured 
so that the data link stage will only respond to 
messages received in order from other nodes. If any 

15 messages are stored in the buffer pool out of order, 

the data link stage will not have acknowledged receipt 
of those messages. If there are messages stored out 
of order, the data link stage then in step 198 
discards all of the out of order messages stored in 

2 0 the buffer pool. 

If there are no out of order stored 
messages, or if all out of order messages have been 
cleared by the data link stage in step 198, the data 
link stage then moves to step 200 wherein it re- 
25 initializes its destination control tables for the 

purpose of resynchronizing its node with the specified 
node in the network. The data link stage then exits. 

Referring now to Figure 8 , it illustrates 
the manner in which the data link stage may be 

3 0 implemented to process an expired timer message from 

the timer manager. This portion of the data link 
stage first receives the time-out message from the 
timer manager in step 2 02. Then, in step 204, the 
data link stage requests from the timer manager 90 the 
3 5 buffer pool storage address of the message whose 

message has timed out. The data link stage then 
discards the timer manager message in step 206 and 
marks the timed-out message as a retransmission 
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message in step 208. The data link stage then will 
process the retransmission of the timed-out message in 
accordance with the transmit procedure previously 
described with respect to the flow diagrams of Figures 
5 through 7. 

Referring now to Figure 9, it illustrates 
the manner in which the data link stage may be 
implemented to respond to a message received from 
another node as determined in step 106 of Figure 4. 
This portion of the data link stage receives a message 
from another node at step 210. The data link stage 
then determines whether the message is a supervisory 
frame in step 212. If the message is a supervisory 
frame or message, the data link stage will process the 
supervisory frame in a manner to be described 
hereinafter with respect to Figure 10. 

If the message is not a supervisory message, 
the data link stage then determines in step 214 if the 
message is a control message. If it is, it will 
process the control message in a manner to be 
described hereinafter with reference to Figures 11 
through 18 . 

If the message is not a control message and 
not a supervisory message, the data link stage will 
then determine in step 216 if the message is a data 
message or frame. If the message is a data message, 
it will process the data message in a manner to be 
described hereinafter with reference to Figures 19 and 
20. 

If the data link stage determines that the 
message is not a supervisory message, a control 
message, or a data message, it will enter into the 
error handling routine and then exit to once again 
receive a message from another node. 

In determining whether the message is a 
supervisory message, a control message, or a data 
message, the data link stage utilizes the message 
header to make that determination. The message 
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header, therefore , enables the data link stage to 
categorize the type of message which is being received 
at its node. 

Referring now to Figure 10, it illustrates 
the manner in which the data link stage may be 
implemented to process a received supervisory frame. 
A supervisory frame is a response frame in the form of 
an acknowledgement to a received message and enables 
the data link stage to provide point-to-point 
reliability within the network. This portion of the 
data link stage first receives the response frame or 
message at step 220. The data link stage then 
determines in step 222 whether its node has been 
suspended. If its node has been suspended, it will 
then discard the message in step 224 and then exit to 
receive the next response message. 



been suspended, then the data link stage will 
determine in step 226 if the received response falls 
within its eight consecutive frame transmit window as 
indicated in its storage table. If it is not, the 
data link stage will discard the response in step 224 
and exit. If the response is within the transmit 
window, the data link stage will then in step 228 
obtain from its table the timer index entry of the 
timer manager for the message which has been responded 
to. The data link stage then in step 230 will use the 
timer entry index to obtain from the timer manager the 
buffer pool storage address of the message and cause 
the timer manager in step 232 to delete the timer 
associated with the message. In step 234, the data 
link stage will then update its transmit window 
because it can now send out one additional message 
onto the bus. 

The data link stage next in step 23 6 
notifies the local task or application module that its 
message had been received by the destined node and 
then determines in step 238 if there are any messages 



If the node of the data link stage has not 
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stored in the buffer pool for which transmission was 
delayed because its transmit window was full. If 
there are no delayed messages stored in the buffer 
pool, the data link stage will then discard the 
response in step 224 and exit to receive the next 
response frame. 

If there are messages stored in the buffer 
pool for which transmission was delayed , the data link 
stage will remove the next message to be transmitted 
from the buffer pool in step 240 and will then 
transmit the message in accordance with the procedure 
previously described with respect to Figures 5 through 
7. The data link stage then determines whether its 
transmit window is now full in step 242. If its 
transmit window is now full, it will then proceed to 
step 224 to discard the response and then exit to 
receive the next response message. If its transmit 
window is not full, then it returns to step 238 to 
determine if there are any further messages to be 
transmitted for which transmission was previously 
delayed because the transmit window was full. 

Referring now to Figure 11, it illustrates 
the manner in which the data link stage may be 
implemented to process a received control frame to 
restart its node if the control frame is a restart 
request and if its node had previously been suspended 
or, if not suspended, categorizes the type of control 
frame being received. Such control frames may be, for 
example, restart messages, reset messages, reject 
messages, suspend messages, or resume messages, for 
example. Before each of these types of control 
messages can be processed, the data link stage must 
categorize the control message as one of these types 
of messages. This categorizing process is performed 
in accordance with the implementation illustrated in 
Figure 11. 

This portion of the data link stage first 
receives the control frame or message in step 250. 
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The data link stage first determines at step 252 if 
its node is suspended. If its node is suspended f the 
data link stage in step 254 next determines if the 
control message is a restart request, if it is not a 
5 restart request, the data link stage will disregard 

the message in step 256 and exit to receive another 
control frame. If the message is a restart request, 
the data link stage, through restart means, first 
resets its suspend status in step 258. The data link 
10 stage next in step 260 formats a restart response 

message to acknowledge receipt of the restart request 
and then transmits the restart response pursuant to 
the procedure previously disclosed with respect to 
Figures 5 through 7. 
15 The data link stage next determines in step 

262 whether any nodes have been communicated with 
prior to its suspension. If no nodes had been 
communicated with prior to its suspension, the data 
link stage discards the message in step 264 and exits 
20 to receive the next control frame. If any nodes had 

been communicated with prior to its suspension, the 
data link stage will have stored the addresses of 
those nodes in its storage 82a. The data link stage 
obtains the first node address in step 266 and formats 
25 a reset request for that node and transmits the reset 

request in step 268. The data link stage then enters 
a reset clean-up routine which will be described 
hereinafter with respect to Figure 13. The data link 
stage then determines if there are any other nodes 
which it communicated with prior to its suspension. 
If there are, it will obtain the next node address 
from its storage and proceed to format a reset request 
for that node, transmit the reset request to that 
node, and perform the reset clean-up procedure. When 
35 th © reset message has been sent to all of the nodes to 

which the data link stage had communicated with prior 
to the suspension of its node, it will discard the 
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reset request: message and then exit to receive the 
next control frame. 

If originally the data link stage found in 
step 252 that its node was not suspended, it then 
proceeds to determine the type of control message that 
it has received. In making this determination, the 
data link stage uses the information contained in the 
header of the message. 

The data link stage first determines if the 
message is a request in step 274. If the message is 
not a request, it is then processed as a control 
response frame in a manner to be described hereinafter 
with respect to Figure 18. If the message is a 
request frame, the data link stage then determines in 
step 276 if the message is a reset message. If it is 
a reset message, the data link stage will process the 
reset request frame in a manner to be described 
hereinafter with respect to Figure 12. If the message 
is a request but not a reset message, the data link 
stage then determines in step 278 if the message is a 
restart message. If the message is a restart message, 
the data link stage will process the restart request 
message in a manner to be described hereinafter with 
respect to Figure 14. If the message is a request, 
but not a reset message, nor a restart message, the 
data link stage then determines in step 280 if the 
message is a reject message. If the message is a 
reject message, it will process the reject message in 
a manner to be described hereinafter with respect to 
Figure 15. If the message is a request, but not a 
reset message, a restart message, nor a reject 
message, the data link stage will then determine in 
step 282 if the message is a suspend request message. 
If the message is a suspend request message, the data 
link stage will process the suspend request message in 
a manner to be described hereinafter with respect to 
Figure 16. If the message is a request message, but 
not any of the previously mentioned types of request 




messages, the data link stage lastly determines in 
step 284 if the message is a resume request message. 
If the message is a resume request message, it will 
process the message in a manner to be described 
hereinafter with respect to Figure 18. If the request 
message is not any of the aforementioned types, the 
data link stage will go into the error handling 
routine, discard the message at step 272 and then exit 
to receive the next control message. 

Referring now to Figure 12, it illustrates 
the manner in which the data link stage may be 
implemented for processing a received reset request 
frame. This portion of the data link stage first 
receives the reset request message in step 290. The 
data link stage next at step 292 logs in its storage 
the receipt of the reset message. Thereafter, in step 
294, the data link stage determines if the message is 
a broadcast reset request. If it is, the data link 
stage immediately goes into the reset clean-up routine 
to be described hereinafter with respect to Figure 13 
without acknowledging receipt of the message. If the 
reset request is not a broadcast message, the data 
link stage then in step 296 formats a reset response 
frame to acknowledge receipt of the reset request and 
then transmits the reset response message in 
accordance with the procedure described with respect 
to Figures 5 through 7. The data link stage then 
proceeds to the reset clean-up procedure to be 
described immediately hereafter. 

Referring now to Figure 13, it illustrates 
the manner in which the data link stage may be 
implemented to perform the reset clean-up procedure in 
response to receiving a suspend request message or a 
reset request message. The data link stage first 
cleans up its control tables in step 300. It does so 
by resetting its tables in its storage 82a so that for 
the given node sending the reset request message, both 
the data link stage of the node under consideration 
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and the data link stage of the node sending the reset 
request message are reset to corresponding receiving 
and sending windows- The data link stage then, in 
step 302, determines if there are any outstanding 
5 messages currently stored in the buffer pool which 

should be transmitted. If there are such messages, 
the data link stage obtains the first message in step 
304 and then in step 3 06 re-tags the message by 
inserting a new frame number into the message header 

10 which will correspond to the frame number to which the 

receiving node will respond. The data link stage next 
in step 308 re-orders the message in proper order, and 
then retransmits the message in accordance with the 
procedure previously described with respect to Figures 

15 5 through 7. The data link stage in step 310 then 

determines if there are any other messages stored in 
the buffer pool which are to be transmitted. If there 
are, it will obtain from the timer manager the buffer 
pool storage address of the next message in step 312 

20 and return to step 306 to re-tag that message. After 

all of the stored messages to be transmitted have been 
sent out onto the bus, the data link stage in step 314 
resets its window counters again to a known level. 

The data link stage next determines in step 

25 316 if there are any delayed messages to be 

transmitted onto the bus. If there are, the data link 
stage in step 318 will obtain from the timer manager 
the buffer pool storage address of the first delayed 
message to be transmitted. The data link stage will 

30 then in step 320 re-order the message to assure that 

the messages are sent out in order when they are later 
transmitted. The data link stage will next determine 
in step 3 22 if there are any other delayed messages 
outstanding. If there are, then the data link stage 

35 will proceed to step 324 to obtain from the timer 

manager the buffer pool storage address of the next 
message that is stored for delayed transmission. The 
data link stage will then perform step 3 20 again to 
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place this message into the proper order for 
transmission. This continues until there are no more 
messages outstanding which have been stored for 
delayed transmission. When this occurs , the data link 
5 stage determines in step 326 whether there are any 

received messages which have been stored out of order. 
If there are, the data link stage will clear those 
messages in step 328, discard the messages in step 
330, and exit. If after re-ordering all of the 

10 messages for delayed transmission there were no 

received messages stored out of order, the data link 
stage would immediately exit. 

Referring now to Figure 14, it illustrates 
the manner in which the data link stage may be 

15 implemented to respond to a received restart request 

message when the node of the data link stage has not 
<\ been previously suspended. This portion of the data 

link stage in step 332 receives the restart request 
message and then logs receipt of the restart request 

20 message in step 334. In step 336, the data link stage 

next determines whether the restart request message is 
a multi-cast or broadcast. If it is not, the data 
link stage in step 338 formats an acknowledgement to 
the restart request message and then transmits the 

25 response to the restart request message in accordance 

with the procedure as previously disclosed with 
respect to Figures 5 through 7. 

After the response has been transmitted to 
the node originating the restart request message or if 

30 the restart request is a broadcast message, the data 

link stage in step 340 determines if it has 
communicated with any other nodes prior to receipt of 
the restart request message. If it has not, it 
discards the restart request message in step 42 and 

35 exits. If it has, it obtains from its storage in step 

344 the address of the first node in its list and then 
in step 346 formats a reset request message to that 
node. It then transmits the message and enters into 



WO 91/11871 




PCT/US91/00257 



the reset clean-up routine as previously described 
with respect to Figure 13. After the reset clean-up, 
the data link stage in step 348 determines whether 
there are any other nodes that it had communication 
with prior to the receipt of the restart request 
frame. If there are no other nodes , it discards the 
restart request message in step 350 and exits. If it 
had, it then repeats the steps immediately described 
for sending reset messages to all of the nodes to 
which it had communicated with prior to the receipt of 
the restart request message one at a time in 
succession until a reset message has been sent to all 
such nodes. 

Referring now to Figure 15, it illustrates 
the manner in which the data link stage may 
implemented for processing a reject request message. 
This portion of the data link stage receives the 
reject request message at step 352. As previously 
mentioned, a reject message informs the receiving node 
that the node originating the reject request message 
has stored the maximum number of received messages in 
its buffer pool and is able to process only high 
priority or critical messages. As a result, in step 
354, the data link stage marks in its table which 
contains the addresses of all of the nodes in the 
network that the node originating the reject request 
frame is only receiving high priority or critical 
messages . 

The data link stage next in step 356 
determines if there are any buffered outstanding 
messages. If there are none, it will discard the 
reject request frame in step 358 and exit. If there 
are buffered outstanding messages, the data link stage 
will obtain the buffer pool storage address of the 
first such buffered message from the timer manager in 
step 358. 

In the next series of steps, the data link 
stage will separate the critical-priority messages 
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from the non-critical priority messages which it has 
stored for transmission to the node originating the 
reject request message. To that end f the data link 
stage in step 358 obtains from the timer manager the 
buffer pool storage address of the first such message* 
It will then determine in step 3 60 from the header of 
the message if the message is of critical priority. 
If it is not of critical priority, the data link stage 
in step 362 will clear the message and then in step 
364 notify the local task or application module 
originating the message that the message could not be 
transmitted. 

The data link stage next in step 366 
requests the timer manager to delete the timer 
associated with the cleared message. The data link 
stage will then discard the message in step 3 68 and 
step 370 will remove the discarded message from its 
control table. The data link stage then in step 372 
determines if there are any other messages which are 
stored for transmission to the node originating the 
reject request frame. If there are none, it will then 
discard the reject frame in step 376 and exit. if 
there are more such stored messages, the data link 
stage then in step 374 obtains from the timer manager 
the buffer pool storage address of the next such 
stored message. If in step 3 60 the data link stage 
determines that this message has critical priority, it 
will skip steps 3 62 through 370 to retain the critical 
priority message in its buffer pool for later 
transmission. Later, in its turn, the data link stage 
will then transmit the critical priority messages to 
the node originating the reject request message in a 
manner as previously described with reference to 
Figures 5 and 6. 

Referring now to Figure 16, it illustrates 
the manner in which the data link stage may be 
implemented to process a suspend request message. 
Such a suspend request message may be originated from 
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a maintenance operator for example, and allows a node 
to be taken off of the bus without physically 
disconnecting the node from the bus. As will be seen 
hereinafter, the data link stage, in response to the 
suspend request frame, precludes its node from 
transmitting any more messages onto the bus by 
clearing all of its memory of messages to be 
transmitted. It also clears messages received out of 
order from other nodes. 

The data link stage receives the suspend 
request message in step 3 80. It logs receipt of the 
suspend message in step 382 and marks in its storage 
the permanent suspension status of its node in step 
384. Then, in step 386, the data link stage discards 
the suspend frame. 

The data link stage then, in step 388, 
determines if it had communicated with any other node 
prior to receiving the suspend request message. If it 
had not, then it exits. If it had, the data link 
stage in step 3 90, obtains from its storage the first 
timer address for a message to be transmitted and uses 
that timer address to obtain from the timer manager 
the buffer pool storage address of the first message 
in step 3 92. From the header of the message, the data 
link stage in step 394 notifies the local task or 
application module that originated the message that 
the message could not be transmitted. The data link 
stage then determines in step 400 if there are any 
more such messages and if there are, it obtains from 
its storage the timer address of the next message in 
step 402. 

If there were no more messages outstanding, 
the data link stage then in step 4 04 determines if 
there are any messages which were stored for delayed 
transmission. If there are such stored messages for 
delayed transmission, the data link stage obtains the 
address of the first message in step 4 06, and 
thereafter in step 408 notifies the local task or 
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application module which originated that message that 
it could not be transmitted. The data link stage 
then, in step 410, deletes the stored message and then 
in step 412 determines if there are any other such 
messages which were stored for delayed transmission. 
If there are additional messages which were stored for 
delayed transmission, the data link stage in step 414 
obtains their addresses and repeats step 408 through 
412. When all of the message which were stored for 
delayed transmission have been cleared from the buffer 
pool, the data link stage then in step 416 determines 
whether there are any stored messages in the buffer 
pool which were received out of order from other 
nodes. Step 416 is also performed immediately after 
step 404 if there were no messages stored in the 
buffer pool for delayed transmission. 

If there are messages stored in the buffer 
pool which were received out of order from other 
nodes, the data link stage then deletes those messages 
from the buffer pool in step 418 and discards those 
messages in step 420. If there were no messages 
stored in the buffer pool which were received out of 
order from other nodes, then the data link stage will 
have immediately exited and would not have performed 
steps 418 and 420. 

Figure 17 illustrates the manner in which 
the data link stage may be implemented to process a 
resume request message. Such a message may be 
received from a node which had previously originated 
a reject message. The purpose of the resume request 
message is to enable a node which previously sent a 
reject message to notify the data link stage that its 
buffer pool is no longer filled with the maximum 
number of stored received messages and is able to 
process all types of messages. 

This portion of the data link stage receives 
the resume request message in step 422. In step 424, 
the data link stage logs the receipt of the resume 
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request message and in step 426 formats an 
acknowledgement to the resume request message. The 
data link stage then transmits the acknowledgement 
message in a manner as described previously with 
respect to Figures 5 through 7. The data link stage 
then in step 428 marks normal transmission in its 
storage, discards the resume request message in step 
430 and then exits. 

Figure 18 illustrates the manner in which 
the data link stage may be implemented to process a 
control response message. This portion of the data 
link stage receives the control response message 
acknowledging receipt of a control frame or message in 
step 432. In step 434 , the data link stage determines 
if the timer associated with the original control 
message to which this response is an acknowledgement 
is active. If it is not, the data link stage in step 
43 6 discards the response message and exits. If the 
message timer is active , the data link stage then in 
step 438 determines if the control response message is 
a reset response. If it is, the data link stage in 
step 440 marks that the reset is no longer in 
progress. If the control response message is not a 
reset response, the data link stage then determines in 
step 442 if the control response is a restart 
response. If it is a restart response, the data link 
stage then in step 444 marks that the restart is no 
longer in progress. If the control response is 
neither a reset response nor a restart response, the 
data link stage in step 446 determines if the control 
message is a reject/resume response. If the control 
message is a reject/ resume response, or if the data 
link stage has marked that either the reset or restart 
is no longer in progress, the data link stage then in 
step 448 updates its eight consecutive frame transmit 
window. It then in step 450 causes the timer manager 
to delete the timer associated with the original 
control message which resulted in the receipt of the 
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control response message. The data link stage then in 
step 452 decrements the message count to reduce its 
record of number of unacknowledged transmitted 
messages by one count. It then discards the control 
response frame in step 436 and exits. 

If the control response frame was not a 
reset response, a restart response or a reject/resume 
response, the data link stage then goes through an 
error handling routine and then exits. 

Figure 19 illustrates the manner in which 
the data link stage may be implemented to process a 
received data message. This portion of the data link 
stage receives the data message in step 460. In step 
462, it then determines if its buffer pool holds the 
maximum number of received messages. if it does not, 
the data link stage in step 464 determines if the 
source node of the data message is listed in its high- 
priority table. The high-priority table is provided 
for listing the addresses of those nodes which sent 
data messages to the node of the data link stage under 
consideration after the data link stage buffer reached 
the maximum number of stored received messages. if 
the node which originated the data message is not in 
that table, the data link stage will handle the data 
message and confirm receipt of the data message in a 
manner to be described immediately hereafter with 
respect to Figure 20. if the source node is listed in 
the table, the data link stage in step 466 will remove 
the source node's address from the table and then in 
step 4 68 format a resume request since it had 
previously sent to that node a reject request. The 
data link stage will then transmit the resume request 
in a manner as previously described with respect to 
Figures 5 through 7 and then handle the data message 
and confirm receipt thereof as will be described 
subsequently . 

If the data link receive buffer holds the 
maximum range of messages, the data link stage then 
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determines in step 470 if the source node of the data 
message is listed in its high-priority table. If it 
is not f it lists the node's address in the high- 
priority table in step 472 and in step 474 formats a 
reject request message to be transmitted to the source 
node. When the source node receives the reject 
request message , it will be advised that only critical 
priority messages are being processed by this node and 
that it should not send any messages to this node 
other than critical priority messages. As a result , 
the data link stage includes limiting means for 
limiting the number of received messages that the node 
can process at any one time* When the buffer pool has 
stored the maximum number of received messages , the 
data link stage will send out reject messages to those 
nodes which are sending data messages to it to inform 
those nodes that only critical priority messages are 
being handled. The addresses of the nodes to which a 
reject message was sent are recorded in the data link 
high priority table so that once the buffer pool 
memory no longer holds the maximum number of received 
messages, the data link stage may format a resume 
request to those nodes when those nodes send another 
message to this node. 

If the source node is listed in the high- 
priority table as determined in step 470 f the data 
link stage in step 476 will determine from the message 
header if the received message has critical priority. 
If it has critical priority, the data link stage then 
proceeds to handle the data message. If it does not 
have critical priority, the data link stage discards 
the message in step 478 and then exits. 

Figure 2 0 illustrates the manner in which 
the data link stage may be implemented for handling 
and confirming receipt of received data messages. This 
portion of the data link stage receives the data 
message in step 480. It then determines in step 482 
if its node is suspended. If its node is suspended, 
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it will discard the message in step 484 and then exit. 

If its node is not suspended, the data link 
stage in step 486 then determines if this is a 
5 broadcasted data message. If it is a broadcasted data 

message, the data link stage in step 488 will transfer 
the data message to the network module and exit. If 
the data message is not a broadcasted message, the 
data link stage then determines in step 490 if the 

10 data message is received within its eight consecutive 

frame window. If it is not, the data link stage in 
step 492 will discard the message and exit. If 
however the data message is received within the data 
link's receive window, the data link stage will 

15 determine in step 494 if the message has been received 

in order. If the message has not been received in 
order, it will log in step 496 that the message was 
received out of order. In step 498, the data link 
stage will store the out of order message in the 

20 buffer pool. Next, in step 500, the data link stage 

will format a response message to acknowledge receipt 
of the last in-order message. The acknowledgement 
message in step 502 is then given a frame number in 
the message header corresponding to the last in-order 

25 received message and then the acknowledgement message 

is transmitted in a manner as previously described 
with respect to figure 5 through 7. The 
acknowledgement message relates to the last in-order 
received message to advise the transmitting node that 

3 0 a message thereafter was received out of order. The 

data link stage then exits. 

If in step 494, it was determined that the 
message was received in order, the data link then in 
step 504 stage formats a response for the highest- 

35 ordered message received to advise the transmitting 

node that all of its messages had been received in 
order. The acknowledgement message is then 

transmitted in a manner previously described with 
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respect to Figures 5 through 7. In step 506, the data 
link stage passes the data message to the network 
stage and in step 508 increments its eight consecutive 
frame receive window. In step 510 f it then determines 
5 if there are any out of order messages to deliver to 

the network stage now that the last data message has 
been received. If there are no such out of order 
messages to deliver, the data link stage exits. If 
there are such messages, the data link stage in step 

10 512 will unbuffer the first such message and then 

proceed to step 506 to pass that data message to the 
network stage. Steps 508 through 512 are repeated 
until all out of order messages have been delivered. 
As a result of the foregoing, when the data link stage 

15 receives a message out of order, it will buffer it, 

but not deliver it to the network stage. When the 
missing message is received, the data link stage then 
acknowledges the highest-ordered message received to 
advise the transmitting node that it has received all 

20 of its messages. Once all of the messages are 

received and in proper order, the data link stage then 
passes the received messages to the network stage for 
the ultimate conveyance to the appropriate application 
modules coupled to the network control system. 

25 

THE NETWORK STAGE 



Figures 21 and 22 illustrate the manner in 
which the network stage 84 of Figure 3 may be 

3 0 implemented for establishing the routing of messages 

to be transmitted onto the bus. Figure 21 

particularly illustrates the manner in which the 
network stage processes messages received from the 
data link stage and Figure 22 illustrates the manner 

3 5 in which the network stage processes messages received 

from the transport stage. 

Referring now to Figure 21, the network 
stage receives a message from the data link stage in 



step 520. In step 522, the network stage first 
determines from the message header if the message is 
destined for a local task or application module. if 
the message is destined for a local task or 
application module, the network stage, in step 524, 
sends the associated message address to the transport 
stage and then exits. 

If the message is not destined for a local 
task or application module, the network stage then 
determines in step 526 if the message is destined for 
a task on its nodes 1 drop. A node drop is a non- 
configured device which may be qoupled to the network 
control system for performing, for example, diagnostic 
services. Such a device is considered non-configured 
because it may be utilized infrequently. However, the 
network stage routing table will be updated with the 
address of the non-configured device as a separate 
node address. This facilitates the network stage re- 
addressing the message in step 528 for the non- 
configured node. Thereafter, in step 530, the network 
stage sends the message to the data link stage and 
then exits. 

If the message is not destined for a local 
application or is not a message destined for a task on 
the node's drop, it may be that this node is an 
intermediary node, receiving the message for the 
purpose of transmitting the message as an intermediate 
source to the final destination of the message. In 
step 532, the network stage determines from the 
message header if its node is an intermediary node. 
If the network stage finds its address in the message 
header as an intermediary node, it will then readdress 
the message in step 534 for the next node to receive 
the message and then sends the message to the data 
link stage in step 530. The next node may be either 
another intermediary node or the node for which the 
message is ultimately destined. If the network stage 
is addressing the message for another intermediary 
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node, it will insert its node's address into the 
header as an intermediary source . If the new address 
is for an intermediary node, the network stage will 
insert into the header the next nodes 1 address as an 
intermediary node. If the new address is for the node 
for which the message is ultimately destined, the 
network stage will also place that node address into 
the header as an intermediary node in accordance with 
the convention previously described. 

Figure 22 illustrates the manner in which 
the network stage may be implemented to process a 
message received from the transport stage 86. The 
network stage receives the message from the transport 
stage in step 540. The network stage next determines 
in step 542 from the message header if the message is 
destined for another link. If the message is destined 
for a node on another link, the network stage will 
then determine in step 544 from its routing table the 
intermediary node address to which the message must 
first be sent before it is ultimately transmitted to 
the destined node. If, in step 544, the network stage 
is unable to find an intermediary node address in its 
routing table, the network stage will then in step 546 
notify the application module originating the message 
of the failure of being able to transmit the message. 
The network stage will then, in step 548, discard the 
message and then exit. 

If the network stage in step 544 is able to 
determine the intermediary node address from its 
routing table, it addresses the message for the 
intermediary node in step 550 and then sends the 
message to the data link stage. As mentioned 
previously, when the network stage addresses a message 
for an intermediary node, it inserts that address into 
the header as an intermediary address and inserts its 
node 1 s address as an intermediary source into the 
header. 
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If the message is not destined for a node on 
another link as determined in step 542, the network 
stage will then determine in step 552 if the message 
is destined for one of its node's drop. If it is f the 
network stage will address the message for the non- 
configured node from its routing table in step 554 and 
then send the message to the data link stage in step 
556. 

If the message is not destined for another 
link as determined in step 542 f nor destined for the 
node's drop as determined in step 552, the message 
then must be destined for a node on the same link. As 
a result, the network stage will, in step 558, address 
the message for the node on its same link. The 
network stage will then send the message to the data 
link stage in accordance with step 556 and then exit. 

As can be seen from the foregoing, the 
network stage serves to route messages which it 
receives either from the data link stage 82 or from 
the transport stage 86. The network stage either 
addresses the messages for an intermediary node or to 
the final destination node address for a node on its 
same link. In this manner, messages are sent from one 
node to another in hops until a message is finally 
addressed by one of the nodes for the destined node. 
In this manner, the network control system is able to 
establish virtual connections between nodes without 
establishing actual connections between nodes as is 
performed in connection-oriented networks . 
Reliability is still provided, however, by virtue of 
the point-to-point confirmation of receipt of messages 
by the data link stages and, as will be more apparent 
hereinafter, the end-to-end confirmation of message 
receipt by the transport stages. 
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THE TRANSPORT STAGE 

Figures 23 through 3 3 illustrate the manner 
in which the transport stage may be implemented. The 
transport stage is arranged for communicating with 
transport stages of other network control systems and 
processes data f supervisory and control messages. The 
transport stage also provides end-to-end reliability 
for messages sent from a node on one link to a node on 
a different link. 

Referring now to Figure 23, it illustrates 
the manner in which the transport stage determines 
from address information in the message headers 
whether a message is destined for another node, is 
from the timer manager, or is a message received from 
another node. The transport stage receives a message 
at step 560. In step 562, the transport stage first 
determines if the message is destined for another 
node. If it is, the transport stage will process the 
message to be transmitted in an manner to be described 
hereinafter with reference to Figure 24. If the 
message is not destined for another node, the 
transport stage then determines in step 564 if the 
message is from the timer manager. If the message is 
from the timer manager, the transport stage will 
process the message as an expired transport time-out 
in a manner to be described hereinafter with reference 
to Figure 25. If the message is not destined for 
another node and is not from the timer manager, the 
transport stage in step 566 then determines if the 
message is from another node. If the message is from 
another node, the transport stage processes the 
received message in a manner to be described 
hereinafter with respect to Figure 26. If the message 
is not destined for another node, is not from the 
timer manager, or is not a message received from 
another node, the transport stage will enter into an 
error handling routine and then exit. 
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Figure 24 illustrates the manner in which 
the transport stage processes a message to be 
transmitted from its node* The transport stage 
receives the message to be transmitted in step 570. 
In step 572, the transport stage determines from the 
message header if the message is a broadcast 
transmission. If it is f services to the message are 
not required by the transport stage and the transport 
stage will then send the message in step 574 to the 
network stage. 

If the message is not a broadcast 
transmission as determined in step 572, the transport 
stage will then in step 576 mark the message priority 
in the message header. This marking is dependant upon 
whether the message is a high priority message such as 
a control or supervisory message, or a low priority 
message such as a data message. 

The transport stage in step 578 then 
determines if end-to-end reliability is required or 
requested for the message. If not, the transport 
stage sends the message to the network stage in 
accordance with step 574. If end-to-end reliability 
is to be provided to the message, the transport stage 
then determines in step 580 if its transmit table is 
full. Like the data link stage, the transport stage 
maintains a table in its own storage 86a, which 
includes a finite number of entries, with each entry 
including a timer manager entry index for each message 
to be transmitted and processed by the transport stage 
and corresponding time-stamps for the message. The 
time-stamps are utilized for identifying and keeping 
track of the individual messages. 

If the transport stage table is full, the 
transport stage will re-queue the message in step 581 
for later transmission when its transmit table is not 
full and then exits. 

If the transport stage transmit table is not 
full, the transport stage will time-stamp the message 
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header in the transport section thereof in step 582, 
will update its control tables in step 584 to include 
this message in its transmit table f and then in step 
586 , will associate a timer with the message. In step 
582 , the transport stage time-stamps the message 
header with the time-stamp of the last message sent 
(old time-stamp) and the time-stamp of the current 
message (new time-stamp) for reasons to be explained 
later. In associating the timer with the message, the 
transport stage will request the timer manager to 
associate a transport timer with the message. As will 
be seen hereinafter, when the timer manager associates 
a transport timer with a message, it conveys to the 
transport stage the transport entry index for the 
message which the transport stage may utilize in 
obtaining from the timer manager the buffer pool 
storage address of the message to be transmitted. 
After the foregoing, the transport stage in step 588 
will mark in its transmit table that a timer has been 
affiliated for use by lower stages, such as the data 
link stage 82, and then will send the message to the 
network stage in step 574. The transport stage then 
exits • 

Referring now to Figure 25, it illustrates 
the manner in which the transport stage may be 
implemented to process an expired time-out message 
from the timer manager. The transport stage receives 
the time-out message at step 590, At step 592, the 
transport stage then obtains from the timer manager 
the buffer pool storage address of the timed-out 
message. The timer manager then, at step 594, 
discards the time-out message from the timer manager. 
At step 596, the transport stage marks the message for 
retransmission and then at step 598, determines 
whether the retransmission count has reached the 
maximum number of retransmissions. If the message has 
not been retransmitted the maximum number of times, 
the transport stage at step 600 uses the same timer 
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previously associated with the timed-out message. The 
transport stage then at step 602, increments the 
retransmit count in its table and then in step 604, 
sends the message to the network stage to begin the 
5 retransmission process. 

If, in step 598, the transport stage 
determines that the message had been retransmitted the 
maximum number of times, it then at step 606 logs the 
retransmission failure. It then determines at step 

10 608 if the retransmission failure was due to the 

retransmission of a reset message. If it was not, it 
then formats at step 610 a reset request message for 
the transport stage of the destined node. It then, at 
step 612, marks that the reset process is in progress 

15 with the transport stage of the destined node and then 

associates in step 614 a new timer with the reset 
message and stores the timer entry index number in its 
table. It then sends the reset message to the network 
stage in step 604 to begin the transmission process of 

20 the reset message. 

If, in step 608, the transport stage has 
determined that the retransmission failure was due to 
the transmission of a reset message, it then causes 
the timer manager in step 616 to obtain the 

25 outstanding message and then causes the timer manager 

in step 618 to clear the message from the buffer pool. 
In step 620, the transport stage then notifies the 
local application module originating the message of 
the transmission failure and then in step 622, 

30 requests the timer manager to delete the associated 

timer. In step 624, the transport stage then 
determines whether all messages have been cleared. If 
not, the transport stage will repeat steps 616 through 
622. If all of the messages have been cleared, the 

35 transport stage in step 626 re- initializes its control 

table and then exits. 

As can thus be seen, if after the 
retransmission of a message to a node on a different 
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link a given number of times has not resulted in the 
transport stage receiving an acknowledgement to the 
message, the transport stage enters into a reset 
routine whereby it attempts to reset itself with the 
transport stage of the destined node. If it is unable 
to reset itself with the destined node f it then causes 
all of the unacknowledged messages to the destined 
node to be cleared from the buffer pool, deletes the 
associated timers, and then re-initializes its control 
tables. 

Referring now to Figure 26 , it illustrates 
the manner in which the transport stage may be 
implemented for processing messages received from 
another node. In this portion of the transport stage, 
the transport stage determines whether the received 
message requires end-to-end acknowledgement, whether 
session services are required for the message, and 
categorizes the message as either a supervisory 
message, a data message, or a control message, and 
processes those different types of message in a manner 
to be described hereinafter. 

The transport stage receives the message 
from another node at step 630. At step 632, the 
transport stage determines whether the message 
requires an end-to-end acknowledgement. If it does 
not, the transport stage then at step 634 determines 
if the message requires session services. If the 
message does require session services, it sends the 
message to the session stage in step 636. If session 
services are not required, it then sends the message 
to the appropriate addressed application module in 
step 638 and then exits. 

If the message requires an end-to-end 
acknowledgement, the transport stage then determines 
in step 640 if the message is a supervisory frame. If 
the message is a supervisory message, the transport 
stage will process the supervisory message in a manner 
to be described hereinafter with reference to Figure 
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27. If the message is not a supervisory message, the 
session stage then determines in step 642 if the 
message is a data message • If the message is a data 
message, it will process the data message in a manner 
to be described hereinafter with reference to Figure 
30. If the message is neither a supervisory message 
nor a data message, the transport module then 
determines in step 644 if the message is a control 
message. If the message is a control message, the 
transport stage will then process the control message 
in a manner to be described hereinafter with reference 
to Figure 31. If the message requires an end-to-end 
acknowledgement and is not a supervisory message, a 
data message, or a control message, the transport 
stage then goes into an error handling routine and 
then exits. 

Referring now to Figure 27, it illustrates 
the manner in which the transport stage may be 
implemented to process a supervisory message. The 
transport stage receives the supervisory message at 
step 650. The transport stage first determines at 
step 652 if the message is a supervisory status 
message. It performs this determination from the 
information contained in the message header. If the 
message is not a supervisory status message, the 
transport stage then determines in step 654 if the 
message is a supervisory acknowledgement message. If 
it is not, the transport stage goes into an error 
handling routine, discards the message at step 656 and 
then exits. If the message is a supervisory 
acknowledgement, it verifies the time-stamp in the 
header of the message in step 658. If it is not, it 
discards the message and exits. If the message is 
within its receive window, the transport stage then 
obtains the timer index entry number of the message 
from its control table in step 660 and then uses that 
index number to obtain the buffer pool storage address 
of the message from the timer manager in step 662. 
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The transport stage then, in step 664, notifies the 
application module originating the message that the 
transmission was successfully received by the destined 
node. In step 666, the transport stage will request 
the timer manager to delete the timer associated with 
the acknowledged message. In step 668, the transport 
stage next determines if the acknowledgement was 
appropriately time-stamped. If not, it marks in step 
670 that the acknowledgement was out of order, 
discards that acknowledgement frame in step 672, and 
then exits. If the acknowledgement was validated, the 
transport stage resets its control window in step 674, 
and then discards the message in accordance with step 
672 and then exits. 

If, in step 652, the transport stage had 
determined that the message is a supervisory status 
message, it then determines in step 676 if the message 
is a suspend status message. If it is, it will 
process the suspend status message in a manner to be 
described hereinafter with respect to Figure 28. 

If the message is not a suspend status 
message, the transport stage then determines in step 
678 if the message is a success status message. If it 
is, it discards the supervisory message in step 680 
and exits. 

If the message is not a suspend status 
message or success status message, the transport stage 
then determines in step 682 if the message is a fail 
status message. Such a message would be, for example, 
a message received from the data link stage which the 
data link stage is conveying to an application module 
to advise the application module that a point-to-point 
acknowledgement had not been received for the 
transmitted message. If the message is a fail status 
message, the transport stage will process the message 
in a manner to be described hereinafter with reference 
to Figure 29. If the message is not a suspend status 
message, a success status message, or a fail status 
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message, the transport stage will go into the error 
handling routine, discard the message in step 680 and 
then exit. 

Referring now to Figure 28, it illustrates 
the manner in which the transport stage may be 
implemented for processing a suspend status message. 
The transport stage receives the suspend status 
message at step 690. It first determines in step 692 
if any nodes had been communicated with prior to 
receiving the suspend status message. The transport 
stage makes this determination by looking into its 
control tables to determine if it has stored therein 
any timer index entries received from the timer 
manager. If there are no such entries, the transport 
stage will be advised that it has not communicated 
with any other transport stage of any other node in 
the network, and therefore, will go into the error 
handling routine, discard the supervisory message at 
step 694 and exit. 

If in step 692, the transport stage 
determines that it had communicated with another node, 
it will obtain from its look-up table the first timer 
entry index in the table. The transport stage will 
then, in step 698, obtain from the timer manager the 
buffer pool storage address of the message and will 
notify the application module originating that message 
in step 700 that there was a failure to transmit the 
message. The transport stage will then, in step 702, 
request the timer manager to delete the timer 
associated with that message, and then in step 704 
request the timer manager to clear that message from 
the buffer pool. The transport stage then in step 706 
determines if there are any other such messages 
outstanding. If there are, it will obtain from its 
look-up table in step 708 the timer entry index for 
the next message and then repeat step 698 through 706. 
When all of the outstanding messages have been 
treated, the transport stage then, at step 710, resets 
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its control tables, discards the supervisory message 
at step 694, and then exits. 

Referring now to Figure 29, it illustrates 
the manner in which the transport stage may be 
implemented for processing a fail status message. The 
transport stage first receives a fail status message 
in step 714. The transport stage then at step 716 
obtains the timer entry index number from its control 
table associated with the failed message and then 
utilizing that index number, obtains from the timer 
manager the buffer pool storage address of the message 
in step 718. The transport stage then notifies the 
application module originating the message that there 
was a failure in the transmission at step 720. The 
transport stage then, in step 722, requests the timer 
manager to delete the timer associated with that 
message. The transport stage then, at step 724, 
requests the timer manger to delete or clear the 
message from the buffer pool. The transport stage 
thereafter in step 726 updates its control table, 
discards the fail status message in step 728 and then 
exits . 

Referring now to Figure 30, it illustrates 
the manner in which the transport stage may be 
implemented for processing a received data message. 
The transport stage receives the data message at step 
730. A message which utilizes transport stage 
services will include in its header the aforementioned 
old and new time-stamps. It first determines in step 
732 if the old time-stamp in the message equals the 
time-stamp of the last message received from the 
sending node. If the old time-stamp does not equal 
the time stamp of the message last received from the 
sending node, the receiving transport stage will be 
35 advised that a previous message had not been received. 

The transport stage will then, in step 734, record 
that the data message includes an invalid time-stamp. 
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The transport stage will thereafter in step 73 6 
discard the data message* 

If the old time-stamp in the message header 
equals the time-stamp of the message last received 
from the sending node, the transport stage will in 
step 738 format an acknowledge message for the sending 
node to provide end-to-end confirmation of receipt of 
the message from the sending node. The 
acknowledgement message is then conveyed to the 
network stage in step 740 for addressing and routing 
to the sending node. 

The transport stage then, in step 742, will 
mark its table with the new time-stamp accorded in the 
message header as the time-stamp of the last received 
message from the sending node so that when the next 
message is received from the sending node, the 
transport stage will be able to perform step 732. The 
transport stage then determines in step 744 if the 
data message just received requires session services. 
If it does, the transport stage in step 746 conveys 
the message to the session stage. If the message does 
not require session services, the transport stage will 
then in step 748 convey the message to the application 
module for which the message is addressed according to 
the destination address in the message header. After 
the message is conveyed to either the session stage or 
to the appropriate application module, the transport 
stage will exit. 

Referring now to Figure 31, it illustrates 
the manner in which the transport stage may be 
implemented to process a control frame. The control 
frame or message may be in the form of a reset 
response, a restart response, a reset request, or a 
restart request. 

The transport stage receives the control 
message in step 750. The transport stage first 
determines in step 752 if the control message is a 
request. If it is not a request, the transport stage 
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then, in step 754, determines if the control message 
is a reset response. If the message is a reset 
response, the transport stage will process the message 
in a manner to be described hereinafter with respect 

to Figure 32. 

If the message is not a reset response as 
determined in step 754, the transport stage will then 
determine in step 756 if the control message is a 
restart response. If the control message is a restart 
response, the transport stage then in step 758 will 
request the timer manager to delete the timer 
associated with the restart request message which 
prompted the received response message. The transport 
stage will also thereafter in step 760 request the 
timer manager to delete the restart request message 
stored in the buffer pool 92 and then exit. 

If the control message is a request message 
as determined in step 752, the transport stage will 
then in step 762 determine if the control message is 
a reset request message. If it is, the transport 
stage will process the reset request message in manner 
to be described hereinafter with respect to Figure 32. 
If the message is not a reset request message, the 
transport stage will then, in step 764, determine if 
the control message is a restart request message. If 
it is a restart request message, the transport stage 
will process the message in a manner to be described 
hereinafter with respect to Figure 33 . If the control 
message is not a reset response, a restart response, 
a reset request, or a restart request, the transport 
stage will then enter into an error handling routine 
and exit. 

Referring now to Figure 32, it illustrates 
the manner in which the transport stage may be 
implemented to process a received reset control 
message. The transport stage first receives the reset 
control message at step 770. The transport stage next 
in step 772 logs receipt of the reset message. It 
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thereafter in step 774 determines if the reset message 
is a reset request message. If it is not a reset 
request message, the transport stage treats the 
message as a reset response message and therefore in 
step 776 requests the timer manager to delete the 
timer associated with the reset request message which 
was sent by its node and which prompted the reset 
response message. The transport stage will also in 
step 778 request that the timer manager delete the 
reset request message stored in the buffer pool. 

If r in step 774, the transport stage 
determines that the reset control message is a reset 
request message, the transport stage will first, in 
step 780, format a reset response acknowledging 
receipt of the reset request message. The transport 
stage then conveys the reset response message to the 
network stage for routing to the node which sent the 
reset request message. After step 778 or step 782, 
the transport stage then determines in step 788 if 
there are any message outstanding to be transmitted to 
the node from which the reset response or reset 
request message was received. If there are no 
outstanding messages, the transport stage discards the 
re set message in step 790 and then exits. If there 
are messages outstanding destined for the node 
originating the reset message, the transport stage 
will then, in step 792, obtain the timer address of 
the first outstanding message from its storage and use 
the timer entry index of the first outstanding message 
to obtain from the timer manager the buffer pool 
storage address of the message in step 794. The 
transport stage then in step 796 resets its retransmit 
count, and then in step 798, provides the message with 
a new time-stamp. The transport stage then, in step 
800, sends the message to the network stage for 
routing to the node which originated the reset 
response or request message. 
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The transport stage then, in step 802, 
determines if there are any more messages outstanding 
for the node from which it received the reset response 
or request message. If there are such additional 
outstanding messages, the transport stage in step 804 
obtains the timer entry index of the next message and 
then repeats steps 794 through 802. When there are no 
more outstanding messages for the node from which the 
control reset message was received, the transport 
stage in step 806 resets its tables, discards the 
reset message in step 790, and then exits. 

Referring now to Figure 33, it illustrates 
the manner in which the transport stage may be 
implemented for processing a received restart request. 
This requires the transport stage to reset itself will 
all nodes within the network. 

The transport stage first receives the 
restart request message at step 810. It logs receipt 
of the restart message in step 812 and then formats a 
restart response in step 814. The transport stage 
then coveys the restart response to the network module 
in step 816. The transport stage then determines in 
step 822 if there are any messages outstanding for the 
node which originated the restart request. If there 
are, the transport stage formats a reset message in 
step 824 and then requests the timer manager in step 
826 to associate a timer with the reset message. The 
transport stage then sends the reset message in step 
828 to the network stage and then in step 83 0 stores 
the timer entry index of the reset message. The 
transport stage then, in step 832, obtains from its 
storage the next node address and then repeats 822 to 
determine if it has any messages outstanding for this 
node. If it does not, then the transport stage in 
step 834 determines if there are any more nodes for 
which it has messages outstanding. If there are, then 
it obtains from its storage the address of the next 
node and repeats steps 822 through 832. When reset 
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messages have been sent to all nodes for which the 
transport stage has messages outstanding, the 
transport stage then discards the restart request in 
step 836 and then exits. 

THE SESSTQN STAGE 

Referring now to Figures 34 through 41, they 
illustrate the manner in which the session stage may 
be implemented for providing messages with session 
services if such session services are required. 

Beginning now with Figure 34 f it illustrates 
the manner in which the session stage may be 
implemented for receiving a long message to be 
transmitted and for beginning to establish a 
connection with the session stage of the receiving 
node. The session stage receives the long message to 
be transmitted at step 850. The session stage, at 
step 852, next determines if the maximum number of, 
for example, four sessions are currently active at its 
node. If all four sessions sure currently active, it 
will go to step 854 to re-queue the message for later 
transmission. The session stage will then exits. 

If the maximum number of sessions are not 
currently active, the session stage, at step 856, will 
determine if there currently is an active session with 
the destined node to receive the long message. If 
there currently is such an active session, the session 
stage will re-queue the message for later transmission 
in accordance with step 854 and exit. 

If there currently is not an active session 
the a node to receive the long message, the session 
will next, in step 858, prepare for the connection 
with the session stage of the node to receive the long 
message. The session stage will first format a 
connect request message in step 860. It will then, in 
step 862, request the timer manager to associate a 
timer with the connect request message and set the 
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timer. Thereafter, the session stage will convey the 
connect request message to the transport stage for 
processing through the transport stage, the network 
stage, and the data link stage, for ultimate 
transmission onto the bus. After sending the connect 
request message to the transport stage, the session 
stage will wait for a connect response from the 
session stage of the destined node. 

Referring now to Figure 35, it illustrates 
the manner in which the session stage may be 
implemented for processing a connect response message 
from the session stage of the node receiving the long 
message. The session stage receives the connect 
response at step 870 and first determines at step 872 
15 if the message is a connect response. If the message 

is not a connect response, the session stage then, at 
step 874, determines if the message is a time-out 
message. If it is not a time-out message, the session 
stage goes into an error handling routine and exits. 
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If the connect response is a time-out 
message as determined in step 874, the session stage 
will format an abort request message in step 876 to 
notify the session stage of the destined node that a 

25 connection cannot be established. It then transfers 

the abort request message in step 878 to the transport 
module for processing and ultimate transmission onto 
the bus to the session stage of the destined node. 
The session stage then, in step 880, notifies the 

3 0 local application module originating the long message 

that the connection was aborted. It discards the 
time-out message in step 882 and then in step 884, 
requests the timer manager to delete the timer it 
associated with the connect request message sent to 

3 5 the session stage of the destined node. Thereafter, 

in step 886, the session stage resets its connect 
phase and exits. 
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If, in step 872, the session stage 
determines that the message is a connect response, it 
will then determine in step 888 if the connect 
response is a positive response. If it is not a 
5 positive connect response, the session stage will 

handle the message in a manner to be described 
hereinafter with respect to Figure 36. 

If the connect response is a positive 
response as determined in step 888, the session stage 

10 will then proceed to divide the packet or long message 

into its first part in step 890 • The session stage 
then formats a data message for the first part of the 
long message and conveys the first part to the 
transport stage in step 894. The session stage next 

15 determines in step 896 if the transmission of the long 

message is complete. If transmission is not complete, 
it will then obtain the next message part in step 898 
and return to step 892 to format a data message 
corresponding to the next part of the message. When 

20 all of the message parts have been transmitted, the 

session stage, in step 900, requests the timer manager 
to set an acknowledgement timer in preparation for 
receiving a data acknowledgement from the session 
stage of the destined node. It thereafter waits for 

25 the data acknowledgement message from the session 

stage of the destined node and will process the data 
acknowledgement message in a manner to be described 
hereinafter with reference to Figure 37. 

Referring now to Figure 36, it illustrates 

3 0 the manner in which the session stage may be 

implemented for processing a negative connection 
response message. In accordance with the present 
invention, the session stage is arranged for 
generating a code and inserting the code into the 

3 5 message header of a negative connection response to 

advise the session stage originating the connect 
request message as to the reason for the negative 
connection response message. The session stage 
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receives the message at step 910. It first determines 
in step 912 if the session was rejected because the 
session stage at the destined node is currently 
managing a maximum number of sessions. If it is, the 
session stage will re-queue the message for future 
transmission in step 914 and then exit. 

If the session was not rejected because the 
session stage at the destined node was not currently 
active in the maximum number of sessions, the session 
stage then determines in step 918 if the session was 
rejected because there is now an active session 
between its node and the destined node. This 
condition may arise, if during the time it was waiting 
for a connect request response, the session stage of 
the destined node initiated a connect request message 
of its own to this node. If that is the case, the 
session stage in step 920 will mark a condition 
referred to as "two-way alternate mode active" in its 
storage 88a and then in step 922, re-queue the message 
for future transmission. The session stage then 
exits . 

If the determinations in steps 912 and 918 
are both negative, the session stage will format a 
close request in step 924. The close request destined 
for the session stage of the destined node is then 
conveyed to the transport stage in step 926. The 
session stage then, in step 928, requests the timer 
manager to associate a timer with the close request 
message and set the timer. The session stage then 
notifies the local application module originating the 
long message that there was a failure in transmitting 
the long message. The session stage then discards the 
response message in step 932, and then waits for a 
hang-up in a manner to be described hereinafter with 
reference to Figure 38. 

Referring now to Figure 37, it illustrates 
the manner in which the session stage may be 
implemented for processing the data acknowledgement 
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message from the session stage of the destined node or 
a time-out message from the timer manager. The 
session stage receives a message at step 934 during a 
time in which it is waiting for a data 
acknowledgement. It first determines in step 936 if 
the message is a data acknowledgement. If the message 
is not a data acknowledgement message, the session 
stage then determines in step 938 if the message is a 
time-out message from the timer manager. If the 
message is a time-out message from the timer manager, 
the session stage will then format an abort request 
message in step 940 for the session stage of the 
destined node and then send the abort request message 
to the transport stage in step 942. The session stage 
then, in step 944, notifies the local application 
module originating the long message that there was a 
failure to communicate with the session stage of the 
destined node, and then will in step 946, discard the 
time-out message. The session stage next, in step 
948, requests the timer manager to delete the data 
acknowledge timer. The session stage then, in step 
950, resets the connection phase and exits. 

If in step 936, it was determined that the 
message is a data acknowledgement, the session stage 
will then determine in step 952 if the transmission 
for this connection is complete. If the session stage 
has more than one long message to send to the session 
stage of the destined node, it will determine that the 
transmission is not complete and will proceed to 
obtain the next packet or long message to transmit in 
step 954. In step 956, the session stage then breaks 
this message packet into its first message part and 
then formats the first message part as a separate data 
message in step 958. It then sends the first message 
part to the transport stage in step 960. The session 
stage then determines in step 962 if all of the 
message parts have been transmitted. If not, the 
session stage will then, in step 964, obtain the next 
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message part and then repeat steps 958 through 962 
until all of the message parts have been transmitted. 
When all of the message parts have been transmitted, 
the session stage, in step 966, will then request the 
timer manager to set an acknowledgement timer and then 
wait for the next data acknowledgement from the 
session stage of the destined node. 

If, in step, 952 it had been determined that 
the transmission of the connection was complete, the 
session stage then formats a close request in step 
968. It then, in step 970, conveys the close request 
message to the transport stage and requests in step 
972 that the timer manager associate a timer with the 
close request message. It then in step 974 notifies 
the local application module originating the long 
message that the message was successfully transmitted 
to the session stage of the destined node and then 
discards the data acknowledgement message in step 976. 
It then waits for a hang-up message in a manner to be 
20 described hereinafter with reference to Figure 38. 

Referring now to Figure 38, the session 
stage receives a message at step 980. The session 
stage first determines if the message is a hang-up 
response in step 982. If it is not a hang-up response 
message, the session stage determines if the message 
is a time-out message from the timer manager in step 
984. If it is not a time-out message, the session 
stage enters an error handling routine and exits. If 
it is a time-out message, it will reset its connect 
phase in step 986 and then in step 988 will discard 
the timer message and request the timer manager to 
delete the associated timer and then exit. 

If the message is a hang-up response message 
as determined in step 982, the session stage will, in 
step 990, request the timer manager to delete the 
timer associated with the close request message. The 
session stage will then, in step 992, determine if it 
had previously marked two-way alternate mode active in 
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step 920 (Figure 36). If it had, the session stage 
then, in step 994, will resynchronize its connect 
phase, discard the hang-up message in step 996 and 
then process the hang-up message as a received connect 
request message in a manner to be described 
hereinafter with respect to Figure 39 • If the session 
stage had not marked the two-way alternate connect 
mode, it resets its connect phase in step 994, 
discards the hang-up message in step 996, and then 
exits . 

Figures 39 through 41 illustrate the manner 
in which the session stage may be implemented for 
receiving a long message from a session stage of 
another node. This process begins with the receipt of 
a connect request from the session stage of the 
destined node and processing the connect request in a 
manner as more particularly illustrated in Figure 39. 

Referring now to Figure 39, the session 
stage first receives a message from the transport 
stage in step 1000. The session stage first 
determines in step 1002 whether the message is a 
connect request or if it had marked a two-way 
alternate mode. If neither, the session stage will 
then enter into an error handling routine and exit. 
If however, the message is either a connection request 
or has a two-way alternate mode marked, the session 
stage will then at step 1004 determine whether it 
currently has the maximum number of sessions active. 
If it does, it will, in step 1006, format a connect 
reject message for the session stage of the 
originating node and then in step 1008, mark the 
reject message with the information that it is 
rejecting the connect request because it has a maximum 
number of sessions currently active. It then conveys 
the connect reject message to the transport stage in 
step 1010. It will then in step 1012 request the 
timer manager to associate a timer with the connect 
reject request, set the timer, and then wait for a 
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close request in a manner to be described hereinafter 
with respect to Figure 41. 

If, in step 1004 f the session stage 
determined that it did not currently have the maximum 
number of sessions active, the session stage will then 
again determine if it has a two-way alternate mode 
marked in step 1014. If it has, the session stage 
will then determine if it is able to acquire a buffer 
for buffering the long message in step 1016. If it is 
unable to acquire a sufficient buffer, it will format 
a connect reject in step 1018, and then mark the 
message with information in step 1120 that it is 
unable to acquire sufficient storage. It then conveys 
the connect reject message to the transport stage in 
step 1010, performs step 1012, and then waits for a 
close request. 

If the session stage is able to acquire a 
sufficient buffer as determined in step 1016, it will 
format a connect acknowledgement in step 1022. It 
then conveys the connect acknowledgement to the 
transport stage for eventual transmission thereof to 
the session stage of the originating node in step 
1024, and will then prepare a connection phase in step 
1026. It will thereafter request the timer manager, 
in step 1028, to associate a timer with the connect 
acknowledgement message and set the timer, and then 
wait for the data in a manner to be described 
hereinafter with reference to Figure 40. 

If, in step 1014, the session stage 
determines that it had not marked a two-way alternate 
mode, it then determines if there is a session 
currently active between this pair of nodes in step 
1030. If it does not have a current session active 
with the other node, it will then proceed to step 
1016, and the steps thereafter. If, however, the 
session stage determines that it does currently have 
a session active with the other node, it then 
determines in step 103 2 if it is currently waiting for 
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a connect acknowledgement from the other node* If 
this node is waiting for a connect acknowledgement, 
this initiates the beginning of a two-way alternate 
mode, wherein this node had sent a connect request to 
5 the other node essentially simultaneously with the 

other node sending a connect request to this node* To 
handle the two-way alternate mode, each session stage 
is provided with a priority with respect to all other 
session stages. As a result, when there are such 

10 simultaneous connect requests between two nodes, one 

node will be a priority node, and the other node will 
be a non-priority node. In step 1034, this node 
determines whether it is a priority node with respect 
to the other node or a non-priority with respect to 

15 the other node. If it is not a priority node, the 

session stage will then in step 1036 re-queue its 
session message for later transmission and then in 
step 1038, mark in its storage 88a that it has a two- 
way alternate mode with the other node. The session 

20 stage then proceeds to step 1016 and the steps 

thereafter to handle the other node's session. 

If the session stage is a priority node with 
respect to the other node, or if it was not waiting 
for a connect acknowledgement, the session stage 

25 proceeds to step 1040 to format a connect reject 

message. If the session stage is the priority node, 
the connect reject message will include information 
advising the other node that this node is the priority 
node and that the other node should mark the two-way 

30 alternate mode at its node. This is accomplished in 

step 1042 wherein the session stage marks the connect 
reject message with session pair active information. 
The session stage then in step 1044 sends the connect 
reject message to the transport stage for further 

35 processing within the network control system for 

eventual transmission thereof onto the bus. The 
session stage then, in step 1046, requests the timer 
manager to associate a timer with the connect reject 
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message and to set the timer* Lastly, in step 1048, 
the session stage then waits for an appropriate close 
request message from the other session stage. 

Referring now to Figure 40, it illustrates 
the manner in which the session stage may be 
implemented for receiving data in the form of message 
parts of a long message from the session stage of 
another node. The session stage receives a message at 
step 1050. It first determines at step 1052 if the 
message is a data message. If the message is not 
data, the session stage will then determine if the 
message is a time-out message in step 1054. If the 
message is not a time-out message, the session stage 
will go into an error handling routine and exit. 

If the message is a time-out message from 
the timer manager, the session stage will then, in 
step 1056, request the timer manager to delete the 
timer associated with the connect acknowledgement 
previously sent to the session stage from which the 
data message is to be received. The session stage 
will then in step 1058 reset its connect phase and 
then in step 1060, format an abort request message for 
the session stage of the node from which data should 
have been received. The session stage will then, in 
step 1062, send the abort request message to the 
transport stage. Thereafter, the session stage will 
discard the time-out message in step 1064 and then 
exit. 

If, in step 1052, it was determined that the 
message is a data message, the session stage will 
then, in step 1066, store the data in the special 
buffer which it had acquired in response to the 
connect request message from the transmitting node. 
The session stage will then, in step 1068, update its 
session connection tables. Thereafter, in step 1070, 
the session stage will determine if transmission of 
all the message parts has been completed. If the 
transmission of all of the message parts has not been 
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completed, the session stage will then, in step 1072, 
request the timer manager to delete the old timer 
associated with the connect acknowledgement message. 
Then, in step 1074, it will request the timer manager 
to associate a new timer with the connect 
acknowledgement message. Thereafter, the session 
stage will wait for more data. 

If, in step 1070, it had been determined 
that all of the message parts had been received, the 
session stage will then in step 1076 send all of the 
data to the application module identified in the 
destination address portion of the header of the 
message. The session stage will then, in step 1078, 
format a data acknowledgement response and then send 
the data acknowledgement response to the transport 
stage in step 1080. The session stage will thereafter 
request the timer manager in step 1082 to delete the 
old timer associated with the connect acknowledgement 
message and in step 1084, request the timer manager to 
associate a timer with the data acknowledgement 
response. The session stage will then in step 1086 
determine if the transmission is complete. If the 
transmission is complete, the session stage will wait 
for a close request in a manner to be described 
hereinafter with reference to Figure 41. If the 
transmission is not complete, the session stage will 
wait for further data. 

Referring now to Figure 41, it illustrates 
the manner in which the session stage may be 
implemented for receiving a close request message. 
The close request is received after all of the data 
message parts have been received and is sent by the 
transmitting session stage in response to the data 
acknowledgement response previously referred to. 

The session stage receives a message in step 
1090. It first determines in step 1092 if the message 
is a close request message. If it is not, the session 
stage will then determine in step 1094 if the message 
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is a time-out message from the timer manager. If the 
message is not a time-out message, the session stage 
will go into an error handling routine and exit. 

If the message is a time-out message from 
the timer manager, the session stage will format a 
close request in step 1096, and then send the close 
request message to the transport stage in step 1098. 
The session stage then, in step 1100, requests the 
timer manager to delete the old timer associated with 
the data acknowledgement response. In step 1102, the 
session stage then requests the timer manager to 
associate a new timer with the close request message 
and to start the timer. The session stage then, in 
step 1104 , discards the time-out message and then in 
step 1106 waits for a hang-up message in a manner as 
previously described with reference to Figure 38. 

If, in step 1092, it was determined that the 
message was a close request, the session stage will 
then in step 1108 format a hang-up response. In step 
1110, the session stage then requests the timer 
manager to delete the timer associated with the data 
acknowledgement response and then discards the close 
message in step 1112. 

The session stage then determines in step 
1114 if the two-way alternate mode is active. If it 
is not, it resets its connect phase in step 1116 and 
then in step 1118 sends the hang-up response to the 
transport stage and then exits. If the two-way 
alternate mode is active, the session stage then 
resynchs its connect phase in step 112 0 to maintain 
the connection with the other session stage. It then, 
in step 1122, marks the hang-up as a connect request 
continue message and then requests the timer manager 
to associate a timer with the connect request continue 
message. It then, in step 1126, sends the hang-up 
message in the form of the connect request continue 
message to the transport stage and then waits for a 




W0 9,/l,87i m PCT/US91/00257 
™ 74 V 

connect response in a manner as previously described 
with respect to Figure 35. 

As can be seen from Figure 41, if the two- 
way alternate mode is active, the session stage of 
lower priority has an opportunity to complete its 
session with the session stage of higher priority. 
This is accomplished by reformatting the hang-up 
response as a connect request continue message which 
the other session stage will treat as a connect 
request message. The lower priority session stage 
then will receive a connect request acknowledgement 
from the other higher priority session stage, will 
then divide its long message into message parts, and 
then transmit the data message parts to the higher 
priority session stage. This process continues as 
previbusly described until all of the message parts 
have been transmitted to the higher priority session 
stage, at which time, the higher priority session 
stage sends a data acknowledgement. After receiving 
the data acknowledgement, the lower priority session 
stage then sends a close request to the higher 
priority session stage which then sends back a hang-up 
request for completing the session. Hence, when two 
session stages simultaneously send a connect request 
to each other, both session stages are given an 
opportunity to complete their sessions with the other 
by the two-way alternate mode. 
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Figures 42 through 50 illustrate the manner 
in which the timer manager may be implemented. 
Referring now to Figure 42, it illustrates the manner 
in which the timer manager may be implemented for 
classifying the type of request it may receive from 
one of the other stages of the network control system. 
The timer manager receives a message at step 1130. it 
first determines if the message is a request to add a 
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timer in step 1132. If the message is a request to 
add a timer, it will process the request in a manner 
to be described hereinafter with respect to Figure 43. 
If the message is not a request to add a timer , the 
timer manager then, in step 1134, determines if the 
request is to set a timer. If the request is to set 
a timer, it will handle the set timer request in a 
manner to be described hereinafter with respect to 
Figure 44. 

If the message is not a request to add or 
set a timer, the timer manager will then, in step 
1136, determine if the request is for a message 
address. This type of request may be from either the 
data link stage, the transport stage, or the session 
stage, to determine the address of a message. If the 
request is for a message address, the timer manager 
will process the message in manner to be described 
hereinafter with respect to Figure 45. 

If the message is not a request to add a 
timer, to set a timer, or for a message address, the 
timer manager will then determine if the message is a 
check time request. As will be seen hereinafter, a 
check time request is internally generated within the 
timer manager for determining if any timer associated 
with a given entry in its table has timed out. If the 
timer has timed out, it then notifies the appropriate 
stage that its timer had timed out for a message. The 
timer manager handles the check time request in a 
manner to be described hereinafter with reference to 
Figure 46. 

Lastly, the timer manager, in step 1140, 
determines if the message is a request to delete a 
timer. If it is a request to delete a timer, the 
timer manager will delete the timer in a manner to be 
described hereinafter with reference to Figure 50. If 
the message received by the timer manager is none of 
the above, the timer manager then enters an error 
handling routine and then exits. 
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Referring now to Figure 43, it illustrates 



the manner in which the timer manager may be 
implemented for processing an add timer request. The 
timer manager receives an add timer request in step 
1150 • The timer manager first obtains in step 1152 an 
available timer entry in its table. As previously 
mentioned, a dedicated portion of the buffer pool is 
reserved for the timer manager to establish a multiple 
entry table for associating a timer as requested with 
the entry in the table. The add timer request may be 
made by the session stage, the transport stage, or the 
data link stage. In step 1154, the timer manager will 
then mark in its table that the available timer entry 
is in use. It will then store the buffer pool storage 
address received by the requesting stage for the 
message to be associated with the requested timer in 
the available entry. In step 1158, the timer manager 
determines if the add timer request was from the 
transport stage. If it was, it then, in step 1160, 
sends the table entry index number to the transport 
stage to permit the transport stage to update its 
index in its storage 86a. The timer manager then, in 
step 1162, marks the timer associated with the 
transport service in its table. 



transport services as determined in step 1158 , the 
timer manager, in step 1164, determines if the timer 
is to be associated with data link services. If it 
is, it marks the timer affiliated with the data link 
service in step 1166. It performs this step also 
after step 1162 if both the transport stage and the 
data link stage require a timer. After marking the 
timer affiliated with the data link service in step 
1166, the timer manager in step 1168 then sends the 
timer entry index number to the add timer requester. 



If the timer is not associated with 



If the add timer request was not from the 
data link stage or the transport stage, the timer 
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manager determines in step 1170 if the add timer 
request was from the session stage. If it was not 
from the session stage , the timer manager goes into an 
error handling routine and then exits. If the add 
timer request was from the session stage, it will 
update its session stage index in its table in step 
1172, mark the timer affiliated with the session stage 
request in its index at step 1174, and then send the 
timer entry index to the session stage in step 1168. 
The timer manager then exits to receive the next add 
timer request. 

Referring now to Figure 44, it illustrates 
the manner in which the timer manager may be 
implemented for setting a timer in response to a set 
timer request. The timer manager receives the set 
timer request in step 1180. It first determines if 
the request is for a data link timer in step 1182. If 
it is, it will mark in step 1184 that the data link 
timer is active and then enter the time-out value into 
its appropriate entry in step 1186. It will then 
also, in step 1188, store the data link table index 
with the message frame number in step 1190. It will 
also mark in its table whether the message is a data 
message, a response message, or a control message. 
The timer manager then in response to a message 
received from the transmit/ receive module, starts the 
timer in step 1194. When the transmit/receive module 
obtains the message from the buffer pool and places 
the message onto the bus, it causes the timer manager 
to start the associated timer. After the associated 
timer is started the timer manager exits. 

If it was determined in step 1182 that the 
request to set the timer was not for a data link 
timer, the timer manager then determines in step 1196 
if the request was to set a session timer. If it was 
not, the timer manager goes into an error handling 
routine and exits. If it was a request to set a 
session timer, the timer manager in step 1198 marks in 
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its table that the session timer is active, it then, 
in step 1200, enters the time-out value for the timer. 
It then, in step 1202, stores in its table entry the 
session packet identification number. It then starts 
the timer in step 1204 responsive to the 
transmit/receive module, and then exits. 

Referring now to Figure 45, it illustrates 
the manner in which the timer manager may be 
implemented for processing a message address request. 
The timer manager receives the message address request 
in step 1210. The request will include the timer 
manager table entry index and from the request, the 
timer manager acquires the timer table entry, it then 
uses the timer table entry obtained in step 1212 to 
obtain from its table in step 1214 the buffer pool 
storage address of the message and sends the buffer 
pool storage address of the message to the requester. 
The timer manager then exits. 

Referring now to Figure 46, it illustrates 
the manner in which the timer manager may be 
implemented for checking the condition of the various 
timers associated with timer entries in its table. 
The timer manager generates the check-time request at 
step 1220. in step 1222, the timer manager obtains 
the first timer entry in its table. it then 
determines in step 1224 if this timer entry is in use. 
If it is not, the timer manager then, in step 1226, 
determines if this entry is the last entry in its 
table. If it is, the timer manager exits. If it is 
not the last entry in its table, the timer manager 
will then obtain the next entry in its table in step 
1228 and then return to repeat step 1224. 

If it finds a timer entry in use, it will 
then determine in step 1230 if this timer entry is for 
an active data link timer. If it is, it will handle 
the data link timer in a manner to be described 
hereinafter with reference to Figure 47. If the entry 
is not for an active data link timer, the timer 
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manager will then determine in step 1232 if the timer 
entry is for an active transport timer. If it is, it 
will handle the active transport timer in a manner to 
be described hereinafter with reference to Figure 48. 
If the entry is not for an active data link timer or 
an active transport timer, the timer manager then 
determines in step 1234 if the timer entry is for an 
active session timer. If it is, it handles the active 
session timer in a manner to be described hereinafter 
with reference to Figure 49. If the timer entry is 
not an active data link timer, an active transport 
timer or an active session timer, it will enter an 
error handling routine and then exit. 

Referring now to Figure 47, it illustrates 
the manner in which the timer manager may be 
implemented for handling a data link timer entry. The 
timer manager first generates a countdown request in 
step 1240. It then decrements the timer count 
associated with entry in step 1242. The timer manager 
then determines if the timer has expired in step 1244. 
If the timer has not expired, the timer manager exits. 
If the timer has expired, it will mark the data link 
timer entry inactive in step 1246. It will then, in 
step 1248, format a time-out message to be sent to the 
data link stage. In step 1250, it will then include 
in the time-out message the buffer pool storage 
address of the timed-out message. In step 1252, it 
will include into the time-out message the data link 
entry index of the message and its associated timer 
and in step 1254, it will include in the time-out 
message the frame sequence number assigned to the 
message. The timer message will thereafter in step 
1256 send the time-out message to the data link stage. 
The timer manager then exits to generate the next 
countdown request . 

Referring now to Figure 48, it illustrates 
the manner in which the timer manager may be 
implemented for handling a transport timer entry. In 
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step 1260, it generates a countdown request and in 
step 1262 , will decrement the transport timer counter. 
In step 1264, the timer manager then determines if the 
timer has expired- If the timer has not expired, the 
5 timer manager exits- If the timer has expired, it 

will mark in step 1266 the transport timer entry 
inactive. It will then r in step 1268, format a time- 
out message. In step 1270, it includes in the time- 
out message the buffer pool storage address of the 

10 message associated with the timed-out timer, and then 

in step 1272, includes in the time-out message the 
transport timer entry index. It then, in step 1274, 
sends the time-out message to the transport stage. 
The timer manager then exits to generate the next 

15 countdown request. 

Referring now to Figure 49 , it illustrates 
the manner in which the timer manager may be 
implemented for handling a session timer. In step 
1280, the timer manager generates a countdown request. 

20 in response to the internally generated countdown 

request, the timer manager, in step 1282, decrements 
the session timer count. The timer manager then, in 
step 1284, determines if the timer has expired. If 
the timer has expired, the timer manager exits. if 

25 the timer has not expired, the timer manager then in 

step 1286 marks in its table that the session table is 
inactive. It then formats a time-out message in step 
1288 and updates the time-out message with the session 
timer index in step 1290 and the packet identification 

3 0 number in step 1292. It then sends the time-out 

message to the session stage in step 1294. The timer 
manager then exits to generate the next session 
countdown request . 

Referring now to Figure 50, it illustrates 

35 the manner in which the timer manager is implemented 

in accordance with this preferred embodiment for 
handling a delete timer request. A delete timer 
request may be received by the timer manager from the 
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data link stage , the transport stage , or the session 
stage. These stages make such a request after one of 
these stages receives an acknowledgement response 
within the predetermined timer period established by 
the timer manager within the appropriate table entry 
after the associated message is placed onto the bus by 
the transmit/ receive module 80. 

The timer manager receives the delete timer 
request at step 1300. The timer manager first 
determines in step 1302 if the request is for the 
deletion of a data link timer. If the request is not 
for the deletion of a data link timer, the timer 
manager then determines in step 1304 if the request is 
for the deletion of a transport timer. If the message 
is not for the deletion of a data link timer or a 
transport timer, the timer manager then, in step 1306, 
determines if the request is for the deletion of a 
session timer. If the request is not for the deletion 
of a data link timer, a transport timer, or a session 
timer, the timer manager enters an error handling 
routine and exits. 

If the request was for the deletion of a 
data link timer, the timer manager then r in step 1308, 
marks the data link timer inactive in its table entry. 
The timer manager then determines in step 1310 if this 
timer is affiliated with a transport request. If it 
is, it will mark the transport timer active in step 
1312. Then, in step 1314, the timer manager enters 
the predetermined time-out value for the transport 
timer in its table entry and immediately thereafter on 
its own, starts the transport timer in step 1316. The 
timer manager then exits. 

If it is determined in step 1310 that the 
timer is not affiliated with the transport request, 
the timer manager in step 1318 will mark in its table 
that the timer table entry is not free. It then 
proceeds to step 1320 wherein it determines if the 
message affiliated with the deleted timer should be 
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deleted. If the message is to be deleted, the timer 
manager, in step 1322 , will clear from the buffer pool 
the stored message and then exit. If the message is 
not to be cleared, the timer manager in step 1324 will 
restore the message for later use and then exit. 

If it was determined in step 1304 that the 
request was for the deletion of a transport timer 
without the deletion of a data link timer, the timer 
manager then, in step 1326, marks the transport timer 
entry inactive. It will then in step 1328 mark in its 
table that this timer entry is now free. It then 
determines in step 1320 if the message associated with 
the deleted timer should be cleared from the buffer 
pool. If it is to be cleared from the buffer pool, 
the timer manager clears the message from the buffer 
pool in step 1322. If the message is not to be 
cleared, but to be used at a later time, the timer 
manager will then, in step 1324, restore the message 
for later use and then exit. 

If it is determined in step 13 06 that the 
request was for the deletion of a session timer, the 
timer manager will in step 1330 mark the session timer 
inactive, and in step 1332, will mark in its table 
that the timer entry is now free. The timer manager 
then exits. 

As can be seen from the foregoing , if a 
timer is affiliated with a message for both data link 
stage and transport stage services, the timer 
associated with the data link stage will first be 
started. Once the data link timer is deleted, the 
timer manager automatically will set the transport 
timer time-out value in that same timer and then start 
the timer on its own. In this manner, the data link 
stage need not be advised about the transport stage 
timer. Also, as can be seen from the foregoing, a 
timer deletion is equivalent to a message deletion 
request. The timer manager maintains information 
within its dedicated portion of the buffer pool as to 
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whether or not the message should be cleared after its 
associated timer is deleted. 
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What: is claimed is: 

1 1. A network control system, for use in a 

2 communication network including a first 

3 plurality of nodes coupled to a first 

4 link of a bi-directional bus, for 

5 controlling the reception and 

6 transmission of messages at one node of 

7 said first plurality of nodes, said 

8 network control system being coupled 

9 between a plurality of application 
!0 modules and said first link of said 

11 bi-directional bus, each said 

12 application module having a unique 

13 address and at least some of said 

14 application modules being arranged to 

15 originate a message and to provide 

16 therewith the address for which said 

17 originated message is destined, said 

18 network control system comprising: 

19 a transport stage coupled to 

each of said application modules 
for conveying messages received at 
said one node and destined for 

23 said application modules at said 

one node to said application 
modules and receiving messages 
originated at said one node by 
27 said application modules; 
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a network stage coupled to 
said transport stage for conveying 
said messages received at said one 
node and destined for said 
application modules at said one 
node to said transport stage and 
for receiving from said transport 
stage messages originated by the 
application modules at said one 
node, said network stage being 
responsive to the destination 
addresses of the messages to be 
transmitted from said one node for 
establishing the routing of said 
messages to be transmitted from 
said one node; and 

a data link stage coupled 
between said network stage and 
said first link of said bus for 
conveying messages received at 
said one node to said network 
stage and for receiving from said 
network stage messages to be 
transmitted from said one node on 
said first link of said bus, 
A control system as defined in Claim 1 
wherein said network includes a second 
link of said bi-directional bus, a 
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bridging node coupling said first link 
to said second link, and a second 
plurality of nodes coupled to said 
second link and wherein said transport 
stage includes confirmation means for 
confirming receipt of messages between 
said one node and any one of said second 
plurality of nodes. 

A system as defined in Claim 2 wherein 
said transport stage is arranged for 
providing a current message to be 
transmitted with a time-stamp of the 
last message transmitted and a time- 
stamp for the current message to be 
transmitted . 

A system as defined in Claim 1 wherein 
said nodes of said network are arranged 
to acknowledge receipt of received 
messages and wherein said data link 
stage is arranged to retransmit a 
message a given number of times in the 
absence of an acknowledgement thereto. 
A system as defined in Claim 1 wherein 
said network is arranged for synchronous 
transmission and reception of messages 
between said nodes and wherein said data 
link stage includes reset means for 
resynchronizing said one node with any 
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one of said other nodes when said one 
node is not in synchronism with any one 
of said other nodes. 

A system as defined in Claim 1 wherein 
said data link stage includes limiting 
means for limiting the number of 
received messages that said one node can 
process at any one time. 
A system as defined in Claim 1 wherein 
said data link stage includes suspend 
means responsive to a suspend request 
message for suspending said one node to 
preclude said one node from transmitting 
messages onto said bus. 

A system as defined in Claim 7 wherein 
said data link stage further includes 
restart means responsive to a restart 
request for conditioning said one node 
to resume the transmission of messages 
onto said bus. 

A system as defined in Claim 1 wherein 
said network is capable of conveying 
messages having a length up to a 
predetermined number of bytes and 
wherein said system further includes a 
session stage coupled between said 
application modules and said transport 
stage of said one node for providing a 
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9 session service including dividing a 

10 long message having a length greater 

11 than said predetermined number of bytes 

12 into message parts having lengths less 

13 than said predetermined number of bytes 

14 and for conveying said message parts in 

15 sequence to said transport stage* 

1 10 • A method for use in a communication 

2 network of the type including a first 

3 plurality of nodes coupled to a first 

4 link of a bi-directional bus, for 

5 controlling the reception and 

6 transmission of messages at one node of 

7 said first plurality of nodes, said one 

8 node being associated with a plurality 

9 of application modules wherein each said 

10 application module has a unique address 

11 and at least some of said application 

12 modules are arranged to originate a 

13 message and to provide therewith the 

14 address for which said originated 

15 messages are destined, said method 

16 comprising the steps of: 

17 providing a transport stage 

18 and coupling said transport stage 

19 to said application modules; 

20 conveying messages received 

21 at said one node and destined for 
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said application modules at said 
one node through said transport 
stage to said application modules 
and conveying messages originated 
at said one node by said 
application modules to said 
transport stage; 

providing a network stage and 
coupling said network stage to 
said transport stage; 

conveying said messages 
received at said one node and 
destined for said application 
modules at said one node from said 
network stage to said transport 
stage and conveying to said 
network stage from said transport 
stage messages originated by the 
application modules at said one 
node; 

establishing at said network 
stage the routing of said messages 
to be transmitted from said one 
node responsive to the destination 
addresses of the messages to be 
transmitted from said one node; 

providing a data link stage 
and coupling said data link stage 
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between said network stage and 
said first link of said bus; 

conveying messages received 
from said first link for said one 
node through said data link stage 
to said network stage and 
conveying from said network stage 
to said data link stage messages 
to be transmitted from said one 
node; and transmitting from said 
data link stage onto said first 
link of said bus the messages to 
be transmitted from said one node, 
A method as defined in Claim 10 wherein 
said network includes a second link of 
said bi-directional bus, a bridging node 
coupling said first link to said second 
link, and a second plurality of nodes 
coupled to said second link and wherein 
said method includes the further step of 
confirming at said transport stage the 
receipt of messages between said one 
node and any one of said second 
plurality of nodes. 

A method as defined in Claim 11 
including the further step of providing 
at said transport stage a message to be 
transmitted with a time-stamp of the 
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last message transmitted and a time- 
stamp for the current message to be 
transmitted • 

A method as defined in Claim 10 wherein 
said nodes of said network are arranged 
to acknowledge receipt of received 
messages and wherein said method further 
includes retransmitting a message a 
given number of times in the absence of 
an acknowledgement thereto • 
A method as defined in Claim 10 wherein 
said network is arranged for synchronous 
transmission and reception of messages 
between said nodes and wherein said 
method further includes the step of 
resynchronizing at said data link stage 
said one node with any one of said other 
nodes . 

A method as defined in Claim 10 
including the further step of limiting 
at said data link stage the number of 
received messages that said one node can 
process at any one time. 
A method as defined in Claim 56 
including the further step of suspending 
said one node at said data link stage to 
preclude said one node from transmitting 
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5 messages onto said bus responsive to a 

6 suspend request message. 

1 17. A method as defined in Claim 16 

2 including the further step of 

3 conditioning said one node at said data 

4 link stage to resume the transmission of 

5 messages onto said bus responsive to a 

6 restart request. 

1 18 . A method as defined in Claim 10 wherein 

2 said network is capable of conveying 

3 messages having a length up to a 

4 predetermined number of bytes and 

5 wherein said method includes the further 

6 steps of providing said one node with a 

7 session stage coupled between said 

8 application modules and said transport 

9 stage and providing a session service at 

10 said session stage including dividing a 

11 long message having a length greater 

12 than said predetermined number of bytes 

13 into message parts having lengths less 

14 than said predetermined number of bytes 

15 and conveying said message parts in 

16 sequence to said transport stage. 

17 19." A network control system for use in a 

18 communication network for controlling 

19 the receipt and transmission of messages 
2 0 between at least a pair of nodes of said 
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network, wherein said messages include 
short messages having a length less than 
a predetermined number of bytes and long 
messages having a length greater than 
said predetermined number of bytes , said 
network control system being located at 
least at one of said nodes and 

comprising: 

a connectionless network 
control portion for controlling 
the receipt and transmission of 
said short messages; and 

a connection-oriented network 
control portion coupled to said 
connectionless network control 
portion for establishing a 
connection with said other node 
for controlling the receipt and 
transmission of said long messages 
between said pair of nodes. 
A system as defined in Claim 19 wherein 
said communication network includes a 
plurality of links, each link being 
coupled to a plurality of nodes, and 
wherein said connectionless network 
control portion includes a transport 
stage for providing confirmation of 
receipt for messages transmitted from 
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said one node to nodes coupled to 
another link, a network stage for 
establishing the routing of said 
messages transmitted from said one node, 
and a data link stage for providing 
confirmation of receipt for messages 
transmitted from said one node to a node 
coupled to the same link as said one 
node. 

A system as defined in Claim 20 wherein 
said communication network includes 
intermediary nodes coupling said links 
together and wherein said network stage 
is arranged to route messages originated 
at said one node and destined for a 
local node coupled to the same link as 
said one node directly to said local 
node and to route messages originated at 
said one node and destined for a distant 
node coupled to a link different than 
said link to which said one link is 
coupled to one of said intermediary 
nodes • 

A system as defined in Claim 19 wherein 
said connection-oriented network control 
portion is arranged for dividing said 
long messages into short messages and 
transmitting said short messages in 
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series to said other node after 
establishing said connection with said 
other node. 

A data link stage for use in a network 
control system of one node of a 
connectionless communication network, 
said communication network being of the 
type including a plurality of 
synchronized nodes distributed on a 
bi-directional bus, and wherein each 
said node is arranged to acknowledge 
receipt of received messages , said data 
link stage comprising: 

means for causing a message 
to be sent from said one node to 
another one of said nodes to be 
transmitted onto said bus; 

means for causing said 
message to be retransmitted onto 
said bus in the absence of a 
receipt acknowledgement from said 
another node; and 

means for resynchronizing 
said one node with said another 
node after said message is 
retransmitted a given number of 
times. 
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A data link stage for use in a network 
control system of one node of a 
connectionless communication network , 
said communication network being of the 
type including a plurality of nodes 
distributed on a bi-directional bus for 
conveying messages between said nodes f 
and wherein said network control system 
includes storage means, said data link 
stage comprising: means for storing 
messages received at said one node in 
said storage means; and limiting means 
for limiting the number of messages that 
said one node can process responsive to 
the number of messages stored in said 
storage means reaching a maximum number 
of stored messages. 

A data link stage for use in a network 
control system of one node of a 
connectionless communication network , 
said communication network being of the 
type including a plurality of nodes 
distributed on a bi-directional bus for 
conveying messages between said nodes, 
and wherein said network control system 
includes storage means for storing 
messages to be transmitted onto said 
bus, said data link stage comprising: 
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suspend means responsive to a 
suspend request message for 
suspending said one node to 
preclude said one node from 
transmitting messages onto said 

bus ; and 

clearing means for clearing 
from said storage means said 
stored messages to be transmitted 
onto said bus responsive to the 
suspension of said one node. 
A session handling system for use in a 
communication network including a 
plurality of nodes distributed on a 
bi-directional bus for conveying 
messages between said nodes, wherein 
said messages on said bus are limited to 
a given length, and wherein said session 
system provides a session service 
including dividing long messages greater 
in length than said given length into 
message parts each having a length less 
than said given length for transmission 
on said bus, said session system 
comprising: 

a session stage at least at a 
pair of said nodes, each said 
session stage being arranged for 
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initiating a session connection 
with the other session stage for 
transmitting a plurality of 
message parts from its node to the 
other session stage of the other 
node; 

each said session stage 
including means for determining 
which of said pair of nodes is a 
priority node in response to each 
said session stage simultaneously 
initiating a session connection 
with the other said session stage 
to thereby permit completion of 
the session of the priority node 
first ; and 

each said session stage 
further including session 
connection maintaining means for 
enabling the completion of the 
non-priority node session 
immediately after the completion 
of said priority node session and 
before said session connection is 
terminated . 
A system as defined in Claim 26 wherein 
each said session stage is further 
arranged to assemble the message parts 
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of a long message received from the 
other said session stage. 
A network control system, for use in a 
communication network including a 
plurality of nodes distributed on a 
bi-directional bus, for controlling the 
reception and transmission of messages 
at one node of said plurality of nodes, 
said network control system being 
coupled between a plurality of 
application modules and a 
transmit/receive module which is in turn 
coupled to said bi-directional bus, each 
said application module having a unique 
address and at least some of said 
application modules being arranged to 
originate a message and to provide 
therewith the address for which said 
originated message is destined and a 
memory location address, said network 
control system comprising: 

a buffer pool for storing 
messages to be transmitted from 
said one node at memory locations 
corresponding to said memory 
location addresses ; 

a data link stage coupled to 
said application modules for 
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receiving the memory location 
address of a message to be 
transmitted from said one node; 
and 

a timer manager including 
timing means for timing a time 
period up to a predetermined time 
period after said message to be 
transmitted is transmitted; said 
transmit/receive module being 
coupled to said data link stage 
for receiving the memory location 
address of said message to be 
transmitted, coupled to said 
buffer pool for obtaining said 
message to be transmitted for 
transmitting said message onto 
said bus, and coupled to said 
timer manager for starting said 
timing means responsive to 
transmitting said message onto 
said bus. 

A system as defined in Claim 28 wherein 
said network is capable of conveying 
messages having a length up to a 
predetermined number of bytes and 
wherein said system further includes a 
session stage coupled between said 
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244 application modules and said data link 

245 stage and to said buffer pool of said 

246 one node for providing a session service 

247 including dividing a long message having 

248 a length greater than said predetermined 

number of bytes into message parts 
having lengths less than said 

251 predetermined number of bytes and for 

252 conveying said message parts in sequence 

253 from said buffer pool to said 

254 transmit/ receive module. 

255 3 0. A system as defined in Claim 28 further 

25 6 including broadcasting means for 

257 transmitting a broadcast message to a 

25 8 plurality of said nodes simultaneously. 

259 31. A method for use in a communication 

2 6 0 network including a plurality of nodes 

261 distributed on a bi-directional bus, for 

262 controlling the reception and 

263 transmission of messages at one node of 
2 64 said plurality of nodes, said one node 

265 including a plurality of application 

266 modules and a transmit/ receive module 

267 which is coupled to said bi-directional 

268 bus, each said application module having 

2 69 a unique address and at least some of 

270 said application module being arranged 

271 to originate a message and to provide 
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therewith the address for which said 
originated message is destined and a 
memory location address, said method 
comprising the steps of: 

providing a buffer 

pool; 

storing messages to be 
transmitted from said one node in 
said buffer pool at memory 
locations corresponding to said 
memory location addresses ; 

providing a data link stage; 

conveying to said data link 
stage from said application 
modules the memory location 
address of a message to be 
transmitted from said one node; 

providing a timer manager 
including timing means for timing 
a time period up to a 
predetermined time period; 

conveying from said data link 
stage to said transmit/receive 
module the memory location address 
of said message to be transmitted; 

causing said transmit/receive 
module to obtain from said buffer 
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pool said message to be 

transmitted ; 

causing said transmit/ receive 

module to transmit said message 

onto said bus; and 

causing said transmit/ receive 

module to start said timing means 

responsive to transmitting said 

message onto said bus. 
A method as defined in Claim 31 wherein 
said network is capable of conveying 
messages having a length up to a 
predetermined number of bytes and 
wherein said method further includes 
providing a session stage coupled 
between said application modules and 
said data link stage and to said buffer 
pool of said one node and executing a 
session step at said session stage 
including dividing a long message having 
a length greater than said predetermined 
number of bytes into message parts 
having lengths less than said 
predetermined number of bytes and 
causing said message parts to be 
conveyed in sequence from said buffer 
pool to said transmit/receive module. 
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327 33. A method as defined in claim 31 

328 including the further step of 

329 transmitting a broadcast message to a 

330 plurality of said nodes simultaneously • 
3 31 34. A timer manager for use in a network 

332 control system of one node of a 

333 connectionless communication network, 

334 said communication network being of the 

335 type including a plurality of nodes 

336 distributed on a bi-directional bus for 

337 conveying messages between said nodes, 

338 and wherein said network control system 
3 39 includes a buffer pool for storing 

340 messages to be transmitted from said one 

341 node and a data link stage for receiving 

342 the buffer pool storage address of a 

343 message to be transmitted from said one 

344 node and causing said message to be 

345 transmitted from said one node and 

346 causing said message to be accessed and 

347 transmitted onto said bus, said timer 

348 manager being coupled to said buffer 

349 pool and to said data link stage and 

350 comprising: 

351 means for accessing said 

352 buffer pool for establishing a 

353 table including a plurality of 

354 entry slots, each said slot having 
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an associated timer entry index 
and being arranged for storing the 
buffer pool storage address of a 
message to be transmitted from 
said one node; 

means responsive to an add 
timer request from said data link 
stage for locating an available 
entry slot in said table for a 
message to be transmitted; 

means for obtaining the 
buffer pool storage address of 
said message from said data link 
stage ; 

means for storing said buffer 
pool storage address in said entry 
slot; 

means for conveying to said 
data link stage the index of said 
entry slot; 

timing means associated with 
said entry slot; and 

starting means for starting 
said timing means responsive to 
said message being transmitted 
onto said bus. 
A timer manager as defined in Claim 34 
wherein said one node includes a 
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383 transmit/receive module coupled to said 

384 bus for transmitting said message onto 

385 said bus and wherein said timer manager 

386 is also coupled to said transmit/receive 

387 module for starting said timing means 

388 response to the receipt of a set timer 

389 request from said transmit/receive 

3 90 module. 

391 3 6* A timer manager as defined in Claim 34 

392 wherein said network control system 

393 further includes a transport stage for 

394 providing transport services for said 

395 message to be transmitted, and wherein 

396 said timer manager is responsive to a 

397 transport stage add timer request for 

398 associating a transport stage timing 

399 means with said message to be 

400 transmitted. 

401 37 • A timer manager as defined in Claim 34 

402 wherein said network control system 

403 further includes a session stage for 

404 dividing a long message to be 

405 transmitted onto said bus into message 

406 parts for transmission onto said bus in 

407 sequence, said session stage being 

408 coupled to said timer manager, and 

409 wherein said timer manager is responsive 

410 to a session add timer request from said 
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session stage for associating one of 
said timing means with the message parts 
to be transmitted. 




FIG.1 



WO 91/11871 



2/48 



PCT/US91/00257 




FIG. 2 



WO 91/11871 



PCI7US91/00257 



3/48 



18 



32 



BUFFER 
POOL 



92 



82 



APPLICATION 
MODULES 



t 



38a, 38b, 38c 



SESSION 
STAGE 



STORAGE 



TRANSPORT 
STAGE 



I 



STORAGE 




86 



882 



88 



86d 



c84 



NETWORK 
STAGE 



v 



STORAGE 
t 



84a 



± 



TIMER 
MANAGER 



DATALINK 
STAGE 



STORAGE 



82 a 



80 



90 



TRANSMIT/ 
RECEIVE 
MODULE 



I 



BUS 



FIG. 3 SUBSTITUTE SHEET 



WO 91/11871 



PCT/US91/00257 



4/48 



RECEIVE 
MESSAGE 




100 



MESSAGE 
DESTINED FOR 
ANOTHER NODE? 



MESSAGE 
IS FROM 
TIMER 
MANAGER? 



MESSAGE 
IS FROM 
ANOTHER 
NODE? 




ERROR 
HANDLING 









vYES 




TRANSMIT 




MESSAGE 




-A 



08 



(FIS. 5) 



PROCESS 
EXPIRED 
TIME OUT 



-B 



(FIG. 8) 



PROCESS 

RECEIVED 

MESSAGE 



-C 



(FIG. 9) 



FIG. 4 



WO 91/11871 




PCT/US91/00257 



5/48 



TRANSMIT 
MESSAGE 



c 



RECEIVE MESSAGE 
TO TRANSMIT 




114 



G. 



1 



MESSAGE 
IS RESPONSE 
FRAME ? 



SEND 
ANSMI 



T MODULE/ 




YES 



HIGH PRIORITY 
TRANSFER ONLY? 



MESSAGE IS 
CRITICAL ? 



r 



124 



K NOTIFY 
LOCAL TASK 



YES 




116 

MESSAGE 
IS A CONTROL 
FRAME ? 



TRANSMIT 
PRE-PROCESS 



< 





NO 




' r 



122 

TRANSMISSION 
LOCALLY 

INITIATED? 



(26 



-A, 
(FIG. 6) 



DISCARD 
MESSAGE 



EXIT 



FIG. 5 



WO 91/11871 



TRANSMIT 
PRE-PROCESS 



6/48 



PCT/US91/00257 



-A 



PROCESS MESSAGE 
BEFORE TRANSMIT. 



130 



^134 



DISCARD 
MESSAGE 



FORCE 
MODE IS 
SUSPENDED ? 



r N0 



FRAME IS A. 
NEW TRANSM ITfON 

? 

YESJ 



MESSAGE IS 
MULTICAST ? 




YES1 



MESSAGE 
A CONTROL 
FRAME ? 



i N0 i 


RETRANSMIT 






FRAME 


(FIG. 7) 


-140 

no/ 


C I44 
'V TRANSMIT 
\WINDOW IS 






/YES 


FULL?^ 




Yno 






Xy-148 


150^ 



146 



DELAY 
BUFFER 
LOCALLY 




NO 



TAG MESSAGE/ 
IPDATED TABLE 



.YES 



FY TASI 
FAILURE 



MARK 
PRIORITY 



160 



REQUEST 
ASSOCIATED 
TIMER 



END TO END 
► SERVICE PROVIDED 
THIS MESSAGE? 
YES 




SEND FRAME 
TO TRANSMIT 
MODULE 

^142 




STORE TIMERS 
ADDRESS v 

158^ 




USE 
ASSOCIATED 
TIMER 

15 6^ 



c 



EXIT 



FIG. 6 



WO 91/11871 



7/48 



• 



PCT/US91/00257 



RETRANSMIT 
FRAME 



^162 

PROCESS ^ 

IN/ 



OUTSTANDING 
MESSAGES 
BUFFERED? 

188 



UNBUFFER 
AND DISCARD 
MESSAGE 




r l90 



NOTIFY TASK 
OF FAILURE 



192 



DELETE 
ASSOCIATED] 
TIMER 



ALL 

UNBUFFEREC 



BUFFERED 
OUT-OF-ORDE 
MESSAGES? 



DISCARD 
OUT-OF-ORDEF 
MESSAGES 



WO 91/11871 



8 / 4# 



PCIYUS91/00257 



PROCESS 
EXPIRED 
TIMER 



-B 



PROCESS 
RECEIVED 
MESSAGE 



-C 



202 



c_ 

RECEIVE TRANS 
MEOUT MESSAG 



m7t\ 



y r 



204 



^ET ADDRESS 
OF TIMED-OUT 
MESSAGES 



206 



DISCARD 
TIMER MESSAGES 







"MARK TI 


WED-OUT 



MESSAGES AS A 
RETRANSMISSION, 



> 


f 






TRANSMIT 


-/ 




MESSAGE 





FIG. 8 



2J0 



RECEIVED 
MESSAGE FROM 
ANOTHER NODE. 



MESSAGE IS 
SUPERVISORY 
FRAME? 



MESSAGE IS 
A CONTROL 
FRAME? 



MESSAGE 
IS A DATA 
FRAME? 




PROCESS 
SUPERVISOR 
FRAME 

(FIG. 10) -C| 



PROCESS 
CONTROL 
FRAME 

(FIG. II) -C2 



PROCESS 
DATA 
FRAME 

(FIG. 19) -C 3 



ERROR 
HANDLING 



FIG. 9 



WO 91/11871 



PCT/US91/00257 



9/48 



PROCESS 
SUPERVISORY 
FRAME 



RECEIVE 
RESPONSE 
FRAME 



RESPONSE WITHIN 
TRANSMIT WINDOW? 




220 



222 

TRANSMISSIONS 
SUSPENDED? 



GET TIMER 
ASSOCIATED 
sWITH MESSAGE. 



GET MESSAGE 
ADDRESS FROM 
TIMER MANAGER 




230 



I 



DELETE 
ASSOCIATED 
TIMER 



I 




232 



UPDATE 
TRANSMIT 

WINDOW 



I 




234 



NOTIFY TASK 
OF SUCCESS 



236 



ANY DELAYED 
TRANSMISSIONS? 




REMOVE FROM 
DELAY-QUEUE 




240 



TRANSMIT 
MESSAGE 



WINDOW 
FULL ? 




YES 



242 



NO 



224 



FIG. 10 



Q 

c 



1 



DISCARD 
RES PONSE 

1 — 



EXIT 



WO 91/11871 



1 0 / 4 ff 



PCT/US91/00257 



PROCESS 
CONTROL 
FRAME 



-C 2 



c 



250 



RECEIVE 
CONTROL FRAME 



252 
ARE 

TRANSMISSIONS 
TO THIS NODE 
SUSPENDED? 



256 




DISCARD 
MESSAGE 



c 




) 



MESSAGE IS A 
REQUEST ? 
> 



Z76 



MESSAGE IS 
A RESTART 
REQUEST? RESET, 
MESSAGE? 

258 



RESET SUSPEND 
STATUS 

— r 



260 



FORMAT RESTART 
^RESPONSE MESSAGE. 



> 


t 






TRANSMIT 






A MESSA6E 


-A 



i 



278 



RESTART 
MESSAGE? 




ANY NODE 
COMMUNICATION 
OCCUR? 
YES 



280 



REJECT 
MESSAGE? 



282 



SUSPEND 
MESSAGE? 



FORMAT RE- 
SET REQUEST 



TRANS 
MESSAGE 



mitV 



RESET 
CLEANUP 




284 

(FIG. 5) RESUME 
v 'MESSAGE? 



C 2II 
(FIG. 13) 



274 




PROCESS 
CONTROL 
RESPONSE 
FRAME 



YES 



NO 



COMMUNICATE 
NODES 
REMAIN? 




ERROR 
HANDLING 



(FIG 



-C 
8 




PROCESS 
RESET 

REQUEST 
FRAME 



(F 



-C 
G. U 




PROCESS 
RESTART 
REQUEST 
FRAME 



~ c 2i 
(FIG.I4) 



PROCESS 
REJECT 
REQUEST 
FRAME 



-c 2 : 

(FIG; I 5; 



PROCESS 
SUSPEND 
REQUEST 
FRAME 



-C2- 



(FIG. 16) 



PROCESS 
RESUME 

REQUEST 
FRAME 



-C26 
(FIG. 17) 



NO 



K DISCARD \~ 
MESSAGE J 



272 



FIG. 11 



WO 91/11871 



PCT/US91/00257 



1 1/48 



PROCESS RESET 
R E QU EST FRAME 



-C 2 | 



RECEIVED 

RESET REQUEST 
FRAME 



290 



06 RECEIPT 
OF RESET 



292 



YES 



NKy-294 

/\ MESSAGE 
/ ) MULT I CAST 
\ / REQUEST? 

1N0 



FORMAT RESET 
RESPONSE FRA 



ME/ 



296 



TRANSMIT 
A MESSA6E 



-A 



(FIG. 5) 



RESET 
CLEANUP 



-C2II 
(FIG. 13) 



FIG. 1 2 



WO 91/11871 



PCT/US91/00257 



12/48 



RESET 
CLEANUP 




CLEANUP 
CONTROL TABLES 




300 



C 2ll 

OUTSTANDING 
MESSAGES 
CURRENTLY 
BUFFERED? 




304 



GET FIRST 
LOST) MESSAGE 



312 



1 



7> 



^RE-TAG>i, n< 
V MESSAGE / 3Q( 



c 



REORDER 
MESSAGE 
IN QUEUE 




TRANSMIT 
A MESSAGE 



308 



-A 

(FIG. 5) 



310 



MORE MESSAGES 
OUTSTANDING? 



GET NEXT 
MESSAGE 



YES 




^314 



RESET 
WINDOW 
COUNTERS 



DELAY QUEUE 
MESSAGES' 
OUTSTANDING? 

NO 




316 



318 



YES 



/GET FIRSfN 
\ MESSAGED 

^3 20 



^-324 



/'GET NEXT^ 
VMESSAGE J 



, T 1 z 

f REORDER^ 
VpN QUEUEy 



326 

BUFFERED 
OUT-OF-ORDER 
MESSAGES? 
NOYYES 



YES 




322 

MORE MESSAGES 
OUTSTANDING? 



T--Zl_^328 

-»{UNBUFFER) ^DISCARD^) 



330 



^EXIT^ 



FIG. 13 



WO 91/11871 



PCT/US91/00257 



13/48 



PROCESS 
RESTART 
REQUEST 
FRAME 



-c 22 



RECEIVE RESTART 
REQUEST FRAME 



> 



332 



G 



I 



OG RECEIPT 
OF RESTART 



MESSA6E IS 
MULTICAST 
REQUEST? 

YESL< 



342 



2l 



NODES HAVE 
COMMUNICATED 
WITH THIS ONE? 



DISCARD 
RESTART FRAME 



C 



> 



NO 




> 



334 




338 



FORMAT 
RESTART 
RESPONSE. 



340 



TRANSMIT 
MESSAGE 



-A 



(FIG. 5) 



/" GET Fl RST V 
V NODE J 



344 



c 



346 



FORMAT RESET 
REQUEST MESSAGE 





f 






TRANSMIT 






MESSAGE 


— A 


\ 


f (FIG. 5) 



y 




(FIG.I3) 



MORE NODES HAVE 
COMMUNICATED? 



DISCARD 
RESTART FRA 



me)~ 



350 



EXIT 



FIG. 14 



WO 91/11871 



14 / 48* 



PCT/US91/00257 



PROCESS 
REJECT 

REQUEST 
FRAME 



-C23 



c 



RECEIVE REJECT 
REQUEST FRAME. 



•352 



I 



354 



MARK MESSAGE 
TRANSMIT HIGH 
PRIORITY ONLY 



BUFFERED 
OUTSTANDING 
MESSAGE? 




IK ^358 

ZlSET FIRST \ 
V MESSAGE J 



MESSAGE 
HAS CRITICAL' 
PRIORITY? 




/unbufferV- 
v message j 



362 



YES 



OTIFY TASK 
OF FAILURE 



7 



364 



REQUEST 
DELETION TIMER 



5 



366 



. 1 v /-368 

f DISCARD y 

VMESSA6Ey 



UPDATE 
CONTROL TABLE 



^374 

y GET NEXT\ 
\ MESSAGE J 



MORE 
BUFFERED 
MESSAGES? 

YES 




>^-370 



372 



NO 



37( 



DISCARD 
EJECT FRAM 



FIG.15 



WO 91/11871 



15 / 4 8# 



PCT/US91/00257 



PROCESS 
SUSPEND 
REQUEST 
FRAME 



C24 



RECEIVE 
SUSPEND REQUEST/ 



c 



I 



LOG RECEIPT 
OF SUSPEND 



386 



DISCARD 
SUSPEND 
FRAME 




MARK STATUS 
PERMANENT 
SUSPEND 




388 

ANY NODAL 
COMMUNICATIONS? 



YES 



£--390 



GET FIRST 
IMER ADDRESS 



c 



392 



GET MESSAGE ADDRESS 
FROM TIMER MANAGER 



9 



OTIFY TASK 
OF FAILURE 



5 



394 



DELETE 
ASSOCIATED 



i 



^ 396 
TIMER/ 



£-398 



DELETE 
BUFFERED MESSAGE 



MORE MESSAGES 
OUTSTA NDI NG? 



^402 



GET NEXT 
TIMER ADDRESS 



380 





382 



384 




DELAY 
QUEUE 
MESSACES? 




£l 406 



GET FIRST 
MESSAGE 



408 



OTIFY TASK 
OF FAILURE 



,-'410 



DEL ETE 
BUFFERED 
MESSAGE 



MORE 
DELAYED 
MESSAGES? 




/GET NEXT"\ 

Vmessage J 



BUFFERED 
OUT-OF-ORDER< 
MESSAGES? 



4I6 
vYES, 



4I8 



NO 



■UJNBUFFEPJ 




(^DISCARDj 



420 



EXIT 



FIG. H 



WO 91/11871 



16/48 



PCT/US91/00257 



PROCESS 
RESUME 

REQUEST 
FRAME 



-C 



26 



c 



RECEIVE RESUME 
REQUEST FRAME 



422 



A.OG RECEIPT V\424 
V . OF RESUME J 



c 



FORMAT RESTART 
RESPONSE MESSAGE 



> 



426 



> 


t 






TRANSMIT 
MESSAGE 


-A 

(FIC. 5) 


> 


f 





f MARK NORMAL \^ ' 
V TRANSMISSION/ 4 ' 



G 



DISCARD 
RESUME MESSAGE 



( EX,T ) 



28 



430 



FIG. 17 



WO 91/11871 



PCT/US91/00257 



17/48 



PROCESS 
CONTROL 
RESPONSE 
FRAME 



-C 



27 



c 



RECEIVE CONTROL 
RESPONSE FRAME 




432 




434 

MESSAGE'S 
TIMER IS 
ACTIVE? 

YES 



438 

RESET 
RESPONSE? 



440 




442 

RESTART 
RESPONSE? 



NO 



MARK RESET 

NO LONGER 
IN PROCESS 



MARK RESTART 
NO LONGER IN 
PROCESS 



448 





444 



YE 



UPDATE 
TRANSMIT 
WINDOW 



I 



450 




DELETE 

associated: 

TIMER 



A / 44S 

-/Xreject 

3f /RESUME 
X/RESPONS 



ERROR 
HANDLING 



452- 



DECREMENT 
MESSAGE COUNT 



436' 



DISCARD A 
. RESPONSES 

( exit ) 



FIG. 1 8 



WO 91/11871 



PCT/US91/00257 



18/48 



PROCESS 
DATA 
FRAME 



-c 3 



( RECEIVE N 
VDATA FRAME J 



RECEIVE BUFFER 
HOLDS MAXIMUM 
RANGE OF MESSAGE? 




464 

SOURCE NODE 
LISTED IN HIGH 
PRIORITY TABLE? 

YES 

^466 




NO 



470 

SOURCE NODE 
LISTED IN HIGH 
PRIORITY TABLE? 



[YES 



REMOVE 


SOURCE'S 


ADDRESS 


_ FROM 


TABLE _ 


\ 


f ,-468 


FORMAT 


.RESUME 


REQUEST 



LI 



472 



MARK SOURCE 
NODE ADDRESS 
IN TABLE 



1 



474 



FORMAT REJECT 
REQUEST 



TRANSMIT 
MESSAGE 



-A 
(FIG.5) 




476 

MESS A GE 
HAS CRITICAL 
PRIORITY? 



478 



DISCARD 
ESS AGE 



0 



EXIT 



HANDLE DATA 
MESSAGE/ 
HANDSHAKE 



-C3I 
(FIG. 



20) 



FIG. 19 



WO 91/11871 



19/48 



PCT/US91/00257 



HANDLE 
DATA MESSAGE/ 
HANDSHAKE 



-C 



31 



/HAI 
V2£ 



HANDLE PROCESSING 
DATA MESSAGES 



480 




462 

THIS NODE 
SUSPENDED? 



486 
DATA IS 
MULTICAST? 



484 



C DISCARD^ 
^MESSAGE J 




YES 



DATA 
WITHIN 
RECEIVE 
WINDOW? 



MESSAGE 
RECEIVED 
IN ORDER? 




492 



DISCARD 
MESSAGE 



r^496 
OUT OF A 



LOG 

ORDER RECEIPT 



FORMAT RESPONSE 
MESSAGE. HIGHEST 
ORDER 



48 8 



PASS DATA TO 
NETWORK STAGE 



D 



I 



BUFFER OU"T 
OF ORDER 
MESSAGE 



TRANSMIT 
MESSAGE 



c 



y ^500 



FORMAT RESPONSE 
MESSAGE 



-A 



Q 



(FIG. 5) 



1 



502 



PASS DATA TO 
NETWORK STAGE 



f ^50 8 

/INCREMENT^ 
V WINDOW J 



Ex 



506 



ASSIGN TAG T6\ 
LAST IN ORDER 
RECEIPT y 



TRANSMIT 
MESSAGE 



OUT OF ORDER 
MESSAGES 
TO DELIVER? 




f UNBUFFERA 
V MESSAGE J 



-A 



(FIG. 5") 



FIG. 20 



WO 91/11871 



20 / 



PCT/US91/00257 



C 



RECEIVE 
FROM DATA 



MESSAGE 
LINK STAGE 



520 



MESSAGE 
DESTINED FOR 
LOCAL TASK? 




522 



YES 



NO 

MESSACE 
DESTINED 
FOR TASK. ON 
NODE'S DROP? 

YES 




526 



r 



524 



SEND 
MESSAGE TO 
TRANSPORT 
STAGE 



c 



NO 



INTERMEDIARY 
NODE ADDRESS 
FOUND? 



528 



V f534 



RE ADDRESS 
MESSAGE 



READDRESS 
MESSAGE FOR NON- 
CONFIGURED NODE 




ERROR 
HAN OLINC 



530 



SEND MESSAGE 
TO DATA LINK 
STAGE 



EXIT 



3 



FIG. 21 



WO 91/11871 



21/48 



PCT/US91/00257 



RECEIVE MESSAGE 
FROM TRANSPORT STAGE 



MESSAGE 
DESTINED FOR 
ANOTHER LINK? 

544 

INTERMEDIARY 
NODE ADDRESS 
FOUND? 



546 



OTIFY TAS 
OF FAILURE 



D 




540 



MESSAGE 
DESTINED FOR 
NODE'S DROP? 




Si 



558 



ADDRESS MESSAGE 
FOR SAME 
LINK NODE 



554 



ADDRESS MESSAGE FOR 
ONCONFIGURED NODE 



550 



ADDRESS MESSAGE 
FOR INTERMEDIARY 
NODE 



548 



DISCARD 
MESSAGE 



c 



5 



556 



SEND TO 
DATA LINK 
STAGE 



EX 



FIG. 22 



PCT/US91/00257 



22/48 



f RECEIVE ^ 
VMESSAGEy 



MESSAGE 
DESTINED FOR 
ANOTHER NODE? 




PROCESS 
MESSAGES 
TO BE 
TRANSMITTED 



-E 



(FIG. 24) 



MESSAGE IS 
FROM TIMER 
MAN ACER? 




NO 





PROCESS 




EXPI RED 




TRANSPORT 


r» 


TIMEOUT 



-F 



(FIG. 25) 



MESSAGE 
IS FROM 
ANOTHER NODE? 



YES 






NO 


> 


f 


ERROR 


HANDLING 




f 



PROCESS 
RECEIVED 
MESSAGE 



— G 



(FIG. 26") 



C exit ) 



FIG. 23 



WO 91/11871 



PCT/US91/00257 



TRANSMIT 
TRANSPORT 
MESSAGE 



-E 



RECEIVE 

TO TRANSMI 



23 / ^ « 

messageV. 570 
.nsmit s 



yes 




572 

MESSAGE IS 

MULTICAST 

TRANSMIT? 



MARK MESSAGE 
PRIORITY 



END-TO-END 
RELIABILITY 
REQUIRED OR 
REQUESTED? 




576 



TRANSMIT 
TABLE FULL? 




581 



RE -'QUEUE 



NO 



TIME-STAMP 
RANSMIT HEADER 



UPDATE TRANSPORT 
CONTROL TABLES 



i 



r 



584 



ASSOCIATE 
TIMER WITH 
^MESSAGE STORE 



MARK TIMER 
AFFILIATION 
FOR TIMER 




586 



588 



574 



SEND MESSAGE 
TO NETWORK 



< 



) 



EXIT 



FIG. 24 



WO 91/11871 



PCT/US91/00257 



24/48 



PROCESS 
EXPIRED 
TRANSPORT 
TIMER 



-F 



f RECEIVE TRANSPORT 
^TRANSMISSION TIMEOUT 




G 



6ET ADDRESS OF V 
MED OUT MESSAGE J 



590 



592 



f DISCARD TIMER 
V MESSAGE J 



MARK MESSAGE 
AS RETRANSMIT 



RETRANSMIT 
COUNT HAS 
REACHED 
MAXIMUM? 



600 



USE TIMER 
ASSOCIATED 
JWITH MESSAGE, 



Q 




1 



594 
596 



606 



LOG TRANSPORT 
RETRANSMIT FAILURE 



RETRANSMIT 
FAILURE 
OF RESET 
MESSAGE? 



602 



INCREMENT 
RETRANSMIT 
COUNT 



G 




FORMAT 
REQUEST 



RESET 
MESSAGE 



604 



I 



0 



1 



616 



GET 
OUTSTANDING 
MESSAGE ^ 

618 



I 



CI 



UNBUFFER/ 
DISCARD 
MESSAGE , 



c 



I 



62( 



NOTIFY TASK 
OF FAILURE^ 



I 



622 



DELETE 
[ASSOCIATED j 
TIMER 



NO 



62< 



612 



MARK RESET IN 
PROGRESS FOR 
DESTINED NODE 



ALL 

UNBUFFERED? 



626 



Q 



I 



X 



614 



2 




ASSOCIATE TIMER 
WITH MESSAGE/STORE, 



"RE—INITIATE^ 
CONTROL 
TABLES^ 



SEND MESSAGE TO 
NETWORK STAGE 



( EX,T ) 



FIG. 2i 



WO 91/11871 



PCT/US91/00257 



25 / 48 



PROCESS 
TRANSPORT 
RECEIVED 
MESSAGE 



-G 



RECEIVED MESSAGE V 
FROM ANOTHER NODE/^ 



630 



MESSAGE 
REQUIRES 
END TO END 
ACKNOWLEDGE? 




MESSAGE IS 
SUPERVISORY 
FRAME? 



MESSAGE 
IS DATA 
FRAME? 



MESSAGE IS 
A CONTROL 
FRAME? 



YES 



MESSAGE 
REQUIRES 
SESSION 
SERVICES? 




ERROR 
HANOLING 




1 



636 



SEND MESSAGE 
TO SESSION 
STAGE 



SEND MESSAGE 
TO AODRESS 
NODE 



PROCESS 
TRANSPORT 
SUPERVISORY 
FRAME 



(FIG. 27) 



PROCESS 
TRANSPORT 
DATA FRAME 



— G< 



(FIG. 30) 



PROCESS 
TRANSPORT 
CONTROL 
FRAME 



-6 3 



(FIG. 31) 



C exit ) 



FIG. 26 



WO 91/11871 0^ 



26 / 40 



PCT/US91/00257 



PROCESS 
TRANSPORT 
SUPERVISORY 
FRAME 



-6 



RECEIVE 
(SUPERVISORY 
FRAME 



»6 50 



652 

MESSAGE IS 
SUPERVISORY 
FRAME? 




V ,676 



PROCESS 
SUSPEND 
STATUS 



SUSPEND 
STATUS? 



(FIG. 28) 



PROCESS 

FAIL 
STATUS 



(FIG. 29) 




654 

MESSAGE IS 
SUPERVISORY 
ACKNOWLEDGE? 

658 

TRANSMISSION 
IS WITHIN 
WINDOW? 

YES' 



C 




GET TIMER 
ADDRESS 



) 



DISCARD ^ 
SUPERVISORY 
FRAME ^ 



GET MESSAGE 
ADDRESS FROM 
TIMER MANAGER 



FAIL 

STATUS? 



I 




G62 



ERROR 
HANDLING 



NOTIFY TASK 
O F SUCCES S 

ze: 

DELETE 
ASSOCIATED 
TIMER 



664 




666 



I 



680 



FRAME IS 
ACKNOWLEDGED 
EXPIRED? 



DISCARD 
SUPERVISORY 
FRAME 



c 




JL 



670 



MARK 
ACKNOWLEDGE 
PUT- OF- OR PER. 



RESET CONTROL 
WINDOW 



5 



DISCARD MESSAGE/ 
ACKNOWLEDGE FRAMES 



5 



672 



EXIT 



rv 



FIG. 



27 



WO 91/11871 



PCT/US91/00257 



PROCESS 
SUSPEND 
STATUS 



-6,| 



27 / 4 8 



RECEIVE 
SUPERVISORY 
STATUS 




ANY TRANSMIT LEVEL 
COMMUNICATIONS? 



ERROR 
HANDLINC 



r 



694 



DISCARD 
SUPERVISORY FRAME 



690 




L 



696 



GET FIRST 
MER ADDRESS 



L 



698 



GET MESSAGE 
ADDRESS FROM 
TIMER MANAGER 



700 



OTIFY TASK 
OF FAILURE 



0 



L 



702 



DELETE ASSOCIATED 
TIMER 



I 



704 



DELETE 
BUFFERED MESSAGE 



0 



MORE 
MESSAGES 
OUTSTANDING? 



710 




GET NEXT 
IMER ADDRESS. 

^708 



RESET TRANSPORT 
CONTROL TABLE 



> 



( EX,T ) 



FIG. 28 



WO 91/11871 



PCT/US91/00257 



28 / 48 



PROCESS 

FAIL 
STATUS 



-G| 2 



RECEIVE 
SUPERVISORY STAT 



us)^ 71 



GET TIMER 
ASSOCIATED WITH 
FAILED MESSAGE 




716 



GET MESSAGE 
ADDRESS FROM 
JTIMSR MANAGER 



<3 




718 



OTIFY TASK 
OF FAILURES 



720 



DELETE 
[ASSOCIATED 
TIMER 




722 



DELETE BUFFERED 
MESSAGE 



c 



724 



UPDATE 
CONTROL TABLE 



I 



726 



DISCARD 
SUPERVISORY 
FRAME 




728 



FIG. 29 



WO 91/11871 



Z9 / 4* 



PCT/US91/00257 



PROCESS 
TRANSPORT 
DATA FRAME 



-6 2 



RECEIVE 
DATA FRAME 



c 



734 



LOG DATA WITH 
INVALID TIME-STAMP 



C 




730 



DATA FRAME'S 
OLD TIME-STAMP 
EQUALS LAST 
RECEIVED TIME-STAMP? 



" r 



736 



DISCARD 
DATA FRAME 



C 



(FORMAT AN 
END-TO-END 
ACKNOWLEDGE 




738 



EXIT 



I 



SEND TO 
NETWORK STAGE 



I 



■740 



MARK LAST RECEIVED 
TIME-STAMP WITH 
DATA NEW TIME-STAMP 




742 



MESSAGE 
REQUIRES 

SESSION 
SERVICES? 




r 



746 



SEND MESSAGE 
TO SESSION 
STAGE 



NO 



I 



748 



SEND MESSAGE 
TO APPLICATION 



FIG. 30 



WO 91/11871 



PCT/US91/00257 



30/48 



PROCESS 
TRANSPORT 
CONTROL 
FRAME 



-63 



754 



RESET. 
RESPONSE?\ A NO 



PROCESS RESET 
REQUEST/RESPONSE 



-631 (FIG. 32) 
YES 



DELETE 



758 



ASSOCIA1 


rED TIMER 


\ 


f r 760 



DELETE BUFFERED 
MESSAGE 



5 



RECEIVE 
ROL FRAME 




750 



MESSAGE 
IS A 

REQUEST? 
YES 



RESET 
REQUEST? 



762 
YES 




756 

RESTART 
RESPONSE? 



RESTART 
REQUEST? 



NO 




-764 



NO 



ERROR 
HANDLING 





( EX,T ) 



PROCESS RESET 
REQUEST/RESPONSE 



(FIG. 32) 



YES 




PROCESS 




— >■ 


RESTART REQUEST 



-g 32 Cfig. 33) 



FIG. 31 



WO 91/11871 



31 /4 8# 



PCT/US91/00257 



PROCESS 

RESET 
REQUEST/ 
RESPONSE 



-63, 



c 



RECEIVE TRANSPORT 
RESET REQUEST 



C 



> 



770 



LOG RECEIPT 
OF A RESET 



> 



772 



v r 



776 



NO 



DELETE 
ASSOCIATED 
TIMER 



^778 



C 




774 

REQUEST 
FRAME? 



Y ES ^-7 80 



FORMAT RESE 
RESPONSE 



DELETE 
BUFFERED 
MESSAGE 



782 



SEND MESSAGE TO 
NETWORK STAGE 



MESSAGES 
OUTSTANDING 
AT THIS NODE? 




792 



GET FIRST 
TIMER ADDRESS, 



V ^794 



GET MESSAGE 
ADDRESS FROM 
TIMER MANAGER. 



t r 



796 



RESET RETRANS 
COUNT 



MIT^ 



798 



RE-TIM E-STAM 
MESSAGE 



806 



RESET TABLE V* 



DISCARD 

RESET \ 
MESSAGE J 



( E * IT ) 



-790 



Li 



800 



SEND MESSAGE TO 
NETWORK STAGE 



802^ 



MORE 
MESSAGES? 



NO 




804 



YES/ 6ET NEXT 
v - 5 ' TIMER 

ADDRESS 



FIG. 32 




WO 91/11871 



PCT/US91/00257 



PROCESS 
RESTART 

REQUEST 



-G32 



c 



RECEIVE TRANSPORT 
RESTART REQUEST 



c 




810 



LOG RECEIPT 
OF A RESTART 




FORMAT 
RESP 


RESTART 
ONSE 


> 


1 


SEND M 
TO NE 
STJ 


ESSAGE 
TWORK 




612 



814 



816 



ANY MORE 
NODES? 




MESSAGES 
OUTSTANDING AT 
THIS NODE? 



834 




r 



824 



FORMAT RESET 



MESSAGE 



826 



ASSOCIATE Tl 
WITH MESSAGE 



YES 



G 





NO 


\ 





DISCARD 
RESTART REQUEST 



c 



I 



MER\ 



828 



SEND MESSAGE TO 
NETWORK STAGE 



c 



830 



STORE TIMER 



) 



832 



■^GET NEXT NODE) 



FIG. 33 



WO 91/11871 



PCT/US91/00257 



33/48 



RECEIVE MESSAGE 
FOR TRANSMISSION 
JROM APPLICATION 




850 



MAXIMUM 
NUMBER OF 
SESSIONS 
ACTIVE? 



CURRENT ACTIVE 
SESSION WITH 
REQUESTED 
DESTINATION? 




858 



PREPARE 
CONNECTION 
PHASE 



854 



REQUEUE MESSAGE 
FOR LATER 
TRANSMISSION 



860 



FORMAT CONNECT 
REQUEST MESSAGE, 



0 



862 



ASSOCIATE TIMER" 
WITH MESSAGE/ 
SET TIMER 



SEND TO 
TRANSPORT 
STAGE 



I 



864 



WAIT FOR 
A CORRECT 
RESPONSE 



(FIG. 



-□5 
36) 



c 



EXIT 



FIG. 34 



WO 91/11871 A A, PCT/US91/00257 

34 / 4 6T 



WAIT FOR 
CONNECT 

RESPONSE 



— D 



RECEIVE A 
MESSAGE 




870 



CONNECT, 
RESPONSE? 




874 

TIMEOUT 
MESSAGE? 




YES 



•888 

.POSITIVE 
RESPONSE? 

YES 



ERROR 
HANDLING 



RECEIVE 
NEGATIVE 
RESPONSE 



-Di 



^87 6 
FORMAT ABORT 



(FIG. 36) 



REQUEST 



^87 8 



SEND TO 
TRANSPORT 
STAGE 



c 



^8 80 



896 



/'notify taskA 
v of failure j 



'GET NEXT 
PART OF 
sMESSA GE 



I 



882 



DISCARD MESSAGE/ 
TIMEOUT MESSAGE 



c 



884 



DELETE 
ASSOCIATED 



c 



TIMER/ 



886 



RESET CONNECT 
PHASE 



EXIT 



Q 



i 



L 



890 



BREAK PACKET 
NTO FIRST PART 



(i 



FORMAT 
DATA MESSAGE 



^8 9 2 



894 



SEND TO 
TRANSPORT 
STAGE 




896 

TRANSMISSION OF 
MESSAGE COMPLETE 

SET AN 
ACKNOWLEDGMENT 
TIMER y 



D 2 - 



I 



WAIT FOR DATA ; 
ACKNOWLEDGMENT! 



(FIG. 37) 



FIG. 35 



WO 91/11871 



PCT/US91/00257 



RECEIVE 
NEGATIVE 
RESPONSE 



-°5 



SESSION REJECT 
BECAUSE MAXIMUM 
NUMBER SESSIONS 
ACTIVE? 

YES 



L 



914 



REQUEUE MESSAGE 
FOR FUTURE 
TRANSMISSION 



c 



35 / 4 8 



c 



RECEIVE 
NEGATIVE RESPONSE 





910 



EXIT 



SESSION REJECT 
BECAUSE SESSION 
BETWEEN PAIR 
CURRENTLY ACTIVE? 



MARK TWO WAY 
ALTERNATE MODE 
ACTIVE 



924 



FORMAT CLOSE 
REQUEST 



926 



SEND MESSAGE 
TO TRANSPORT 
STACE 



1 



922 



REQUEUE MESSAGE 
FOR FUTURE 
TRANSMISSION 




I 



928 



ASSOCIATE TIMER 
WITH MESSAGE/SET 
TIMER 



J 



930 



/NOTIFY TASKA 
V OF FAILURE 7 



JL 



932 



DISCARD 
MESSAGE 



> 


f 


WAIT 


FOR 


HANGUP 



(FIG. 38) 



FIG. 36 



WO 91/11871 



36 / 4 8 



PCI7US91/00257 



WAIT FOR DATA 
ACKNOWLEDGMENT 



RECEIVE A^ 
ESSAGE^ 



c 




TIMER 
MESSAGE? 



ERROR 
HANDLINC 



936 
DATA 

ACKNOWLEDGE? 
YES 

952 

TRANSMISSION 
OF CONNECTION 

COMPLETE? £968 

FORMAT A 
OSE REQUEST 



FORMAT ABORT 
REQUEST 



) { 



Get next pac 
to transmi 



942 



956 



SEND TO 
TRANSPORT 
STAGE 



c 



BREAK PACKET 
INTO FIRST PIECE 



JL 



970 



SEND MESSAGE 
TO TRANSPORT 
STAGE 



r-964 



'Get next 

PART OF 
1ESSAGE, 



958-)V 
( FORMAT 

VI 



1 



944 t. 



NOTIFY TASK 
OF FAILURE 



DATA MESSAG 
960-) 



I 



r 



972 



ASSOCIATE T I MER 
WITH MESSAGE 



SEND TO 
TRANSPORT 
STAGE 



946 



DICARD MESSAGE 
TIMEOUT MESSAGE 



948 



DELETE 
ASSOCIATED 
TIMER. 

950 




<5 



I 



974 



OTIFY TASK 
OF SUCCESS 



976 



SET AN 
(ACKNOWLEGMENTJ 
TIMER 



962 

TRANSMISSION 
OF PACKET 
COMPLETE? 

YES 

966 



DISCARD DATA 
ACKNOWLEDGE 



V 



WAIT FOR 
HANGUP 



— D 



(FIG. 38") 



RESET CONN EC 
PHASE 



I 



WAIT FOR DATA 
ACKNOWLEDGE 



1 

( EX,T ) 



FIG. 37 



WO 91/11871 



PCT/US91/00257 



37/48 



WAIT FOR 
HANGUP 



-0, 



f RECEIVE A Vs80 
V MESSAGE J 



TIME ON A 
MESSAGE? 



ERROR 
HANDLING 




c 



DELETE 
ASSOCIATED 
TIMER 



HANGUP 
RESPONSE? 



990 




TWO-WAY 
ALTERNATE 
CONNECT 
REQUEST? 



c 




995 



RESYNC 
CONNE CT PHASE 

997 



I 



0 



£2 



RESET CONNECT 
PHASE 



986 



0 



DISCARD 
HANGUP MESSAGE 



996 



DISCARD HANGUP 
MESSAGE 



RESET CONNECT 
PHASE 



9 



988 



DISCARD TIMER 
NEGATIVE/DELETE 
TIMER 



c 



5 



> 


f 




RECEIVE 






CONNECT 






REQUEST 





(FIG. 39") 



EXIT 



FIG. 38 



WO 91/11871 



PCT/US91/00257 



38/48 



'RECEIVE MESSAGE 
FROM TRANSPORT 
STAGE 




OOO 



ERROR 
HANDLING 



FORMAT 

(CONNECT REJEC 
MESSAGE 



1008 



Q 



MARK MAXIMU 
SESSIONS ACTIVE 




<! 



^ H0I8 



FORMAT CONNECT 
REJECT MESSAGE, 



C 



1020 



MARK MEMORY 
SHORTAGE 



L 



1010 



SEND TO 
TRANSPORT 
STAGE 



Q 



ILL 



1012 



ASSOCIATE TIMER 
WITH MESSAGE/ 
SET TIMER 



CONNECT REQUEST 
FOR TWO WAY 
ALTERNATE 
MARKED? 

1004 

MAXIMUM NUMBER 
OF SESSIONS 
IVE? 

TWO WAY 
ALTERNATE 
REQUEST? 



-103 0 

SESSION 
CURRENTLY 
ACTIVE 
THIS PAIR ? 

* ES 1032 
WAITING 
FOR CONNECT 
ACKNOWLEDGMENT? 

1034 

THIS NODE 
BACKS DOWN? 



1016 

ACQUIRE 
BUFFER FOR 
TRANSMISSION? 

1022 






— r" 10 4 

(FORMAT N 
CONNECT 
REJECTS 
4> ^104 

MARK SESSION 
PAIR AC TIV E 



<5 



10' 



SEND TO 
TRANSPORT 
STAGE 



^I04( 



'ASSOCIATE TIME 
WITH MESSAGE 
SET TIMER, 
| f\04- 



WAIT 
FOR CLOSE 
REQUEST 



(FIG. 41) Oz 



_ * _! >. 



REQUEUE 
SESSION 
Jd ESS A GEL, 
^ r l03 

I ARK TWO- 
WAY ALTERNA 
MODE 



I 



FORMAT CONNECT 
ACKNOWLEDGE MESSAGE 



WAIT FOR 
CLOSE REQUEST 



-°3 (FIG. 41) 



| /HO 24 



( EXIT ) V£ 



SEND TO 
TRANSPORT 
STA GE 

zzx 



1026 



PREPARE 
CONNECTION PHASE 



I 



0 



1028 



ASSOCIATE TIMER 
WITH MESSAGE/ 
SET TIMER 

-D 4 




CFIG. 41) 



FIG. 



3S 



WO 91/11871 



PCT/US91/00257 




-D 4 



39/48 



f RECEIVE A \ 
V MESSAGE J 



1050 



1054 



TIMEOUT 
MESSAGE? 




ERROR 
HANDLINC 



STORE DATA 
IN SPECIAL 
BUFFER 



1056 




1066 



I 



1068 



/delete^ 

V TIMER J 

]f ^1058 



UPDATE SESSION 
CONNECTION 
TABLES 



RESET CONNECT 
PHASE 



c 



I 



5 



END OF 
PACKET 



1060 TRANSFER? 



FORMAT 
AB ORT REQUES T 

~T—r 



1062 



SEND MESSAGE 
FOR TRANSPORT 
STAGE 




1076 



SEND DATA PACKET 
TO APPLICATION 



0 



y ^1076 



FORMAT DATA 
ACKNOWLEDGE 
RESPONSE 



-1064 



DISCARD 
TIMEOUT 
MESSAGES 



WAIT FOR 
DATA 



1080 



SEND TO 
TRANSPORT 
STAGE 



-04 



c 



1082 



DELETE 
OLD TIMER 



JL 



» 

1084 



ASSOCIATE TIMER 
WITH ACKNOWLEDGMENT] 
MESSAGE/SET TIMER 



1086 



( EX,T ) 



WAIT FOR 


* YES < 


CLOSE REQUEST 





-°3 (FIG. 41) 




, NO 




WAIT FOR 




DATA 



SUBSTITUTE SHEET 



TRANSMISSION 
COMPLETE? 



FIG. 40 



WO 91/11871 - - PCT/US91/00257 



40 / 4 8 



WAIT 
FOR CLOSE 
REQUEST 



-°3 



/RECEIVE A\ 
I MESSAGE J 



1090 



CLOSE 
REQUEST? 



ERROR 
HANDLING 



c 




1094 



TIMEOUT 
MESSAGE? 




1108 



FORMAT HANGUP 
RESPONSE 



5 



^HIO 



YES 



FORMAT CLOSE 
REQUEST 



^1096 



C 



DELETE 
ASSOCIATED 
TIMER 

DISCARD A 
CLOSE MESSAGE/ 



1112 



TWO-WAY 
ALTERNATE 
MODE ACTIVE? 




JL 



1120 



SEND MESSAGE 
TO TRANSPORT 
STAGE 



c 



£ 



I 



T 





NO 


--wl098 




1 


f r m6 



^•IIOO 

DELETE OLI 

TIMER w 

^1102 



G 



RESET 
CONNECT PHASE 



'ASSOCIATE TIMER 
WITH NEW MESSAGE/) 
ST ART TIMER 

~7L 



I 



1118 




SEND HANGUP TO 
TRANSPORT STAGE 



1104 



'DISCARD TIMEOUT 
MESSAGE 





> 


f r 


^1106 




WAIT 


FOR 






HANGUP 





(FIG. 38) 



RESYNC 
C ONNECT PHASE 

^ /-1 1 22 

MARK HANGUP AS 
CONNECT REQUEST 
CONTINUE 

^ /-II24 

ASSOCIATE TIMER" 
WITH MESSAGE/ 
SET TIMER 
^ ^1126 



SEND HANGUP TO 
TRANSPORT STAGE 



0|- 



I 



WAIT FOR 
CONNECT RESPONSE 



(FIG. 38) 



FIG. 41 



WO 91/11871 



PCT/US91/00257 



41/48 



( RECEIVE 
yMESSAGEy 



1130 



REQUEST 
TO AOD< 
TIMER? 



REQUEST 
TO SET< 
TIMER? 



REQUEST 
FOR MESSAGE< 
ADDRESS? 



CHECK 
TIME< 
REQUEST? 



REQUEST 
TO DELETE< 
TIMER? 



-1132 
vYES 



NO 



-1134 
.YES 



NO 



NO 



NO 



'NO 



ERROR 
HANDLING 



HANDLE 
ADD TIMER 
REQUEST 



-H, 



(FIG. 43") 



HANDLE 
SET TIMER 
REQUEST 



-H. 



(FIG. 44) 





HANDLE 


, YES ^ 


MESSAGE 




ADDRESS 




REQUEST 



-H3 



(FIG. 45) 





HAN DLE 




CHECK 




TIMER 




REQUEST 



-H 4 



(FIG. 46) 





HANDLE 


.YES 


DELETE 




TIMER 




REQUEST 



-H 5 



(FIG. 50) 



FIG. 42 



WO 91/11871 



42 / 4 8 • 



PCT/US91/00257 



HAN DLE 
ADDRESS 

TIMER 
REQUEST 



-H 



c 



RECEIVE ADDRESS 
TIMER REQUEST 



1150 



GET 
EMPTY TIMER 
TABLE ENTRY 



1152 



MARK TABLE 
ENTRY IN USE 



1154 



STORE ADDRESS OF 
MESSAGE AFFILIATED 
WITH TIMER 



TIMER ASSOCIATED 
WITH TRANSPORT 
SERVICES? 



TIMER ASSOCIATED 
WITH DATA LINK 
SERVICES? 



TIMER ASSOCIATED 
WITH SESSION 
SERVICES? 




1156 



1160 



UPDATE 
TRANSPORT 
STAGE 
INDEX 



1162 



MARK TIMER 
AFFILIATED WITH 
TRANSPORT SERVICE 



1166 



MARK TIMER 
AFFILIATED WITH 
DATA LINK SERVICE 



1172 



UPDATE 
SESSION 
STAGE INDEX 





NO 


\ 


f 


ERROR 


HANDLINC 



I 



1174 



MARK TIMER 
AFFILIATED WITH 
SESSION SERVICES 



— >^ EXIT y^- 



I 



1168 



SEND TIMER 
ENTRY INDEX TO 
STAGE 



FIG. 43 



WO 91/11871 



PCT/US91/00257 



43/48 



HANDLE 
SET TIMER 
REQUEST 



-H 2 ^ 



RECEIVE SET V~ 
IMER REQUEST/ 



REQUEST 
IS FOR DATA 
LINK TIMER? 



1198 



MARK SESSION 
TIMER ACTIVE 



1200 



SET SUSPEND 
TIMER TIMEOUT 
VALUE 



1202 



STORE SESSION 
PACKET ID 



1204 



KICK 
TIMER 



YES 




1180 
1184 



MARK DATA 
LINK TIMER 
ACTIVE 



1196 

REQUEST IS 
FOR SESSION 
TIMER? 



NO 




> 


f 


ERROR 


HANDLING 


> 


f 



( EX,T > 



FIG. 44 



1186 



SET DATA LIN 
TIMER TIMEOU 
VALUE 



Il8f 



STORE DATA 
LINK TABLE 
INDEX 



ll< 



STORE MESSAC 
FRAME NUMBE 



1192 



MARK FRAME 
TYPE 



I 



r 



II9< 



KICK 
TIMER 



HANDLE 
MESSAGE 
ADDRESS 
REQUEST 



-H 



Q 



RECEIVE MESSAGE 
ADDRESS. REQUEST/ 



1210 





> 


\ 








GET 
TABLE 


TIMER 
ENTRY 


-^1212 




> 


f 






RETURN STORED 
ADORESS OF MESSAGE 
TO REQUESTER 


— 1214 



C EXIT ) 

FIG. 45 



WO 91/11871 



44/48 



PCT/US91/00257 



HANDLE 
CHECK TIME 
REQUEST 



-H 4 



c 



GENERATE CHECK 
TIME REQUEST 




1220 



^1228 



GET NEXT 
TIMER ENTRY 



1226 

LAST, 
ENTRY? 




GET FIRST 
TIMER ENTRY 



1222 



T 



YES 



c 



1230 

DATA LINK 
TIMER !S< 
ACTIVE? 

1232- 

TRANSPORT 
TIMER IS< 
ACTIVE? 

1234 

SESSION 
TIMER IS< 
ACTIVE? 



1224 

TIMER 
ENTRY 
IN USE? 

YES 

vYES 





NO 


\ 


f 




ERROR 




HANDLING 



EXIT 



3 



HANDLE 
-H DATA LINK 
TIMER 



-H 4 | 



(FIG. 47) 



,YES 




HANDLE 
TRANSPORT 
TIMER 







-H42 



(FIG. 48) 



YES v 


HANDLE 




SESSION 
TIMER 


> 




-H43 



(FIG. 49) 



FIG. 46 



WO 91/11871 



PCT/US91/00257 



45/48 



HANDLE 
DATA LINK 
TIMER 



— H 4( 



GENERATE 
COUNTDOWN REQUEST 



5~ 



1240 



DECREMENT 
TIMER COUNT 



TIMER HAS, 
EXPIRED? 




1242 



1246 



MARK OATA 
MER IN ACT 



LINKA 
IVE^ 



1248 



FORMAT 
TIMEOUT MESSAGE. 



(mi 



1250 



UPDATE TIMEOUT 
MESSAGE WITH ADDRESS OF* 
MESSAGE BEING TIMED 



I 



is 



1252 



UPDATE TIMEOUT 
MESSAGE WITH DATA 
LINK INDEX 



I 



9 



1254 



UPDATE TIMEOUT 
MESSAGE WITH FRAME 
SEQUENCE NUMBER 



1256 



SEND TIMEOUT 
MESSAGE TO DATA 
LINK STAGE 



C ex,t ) 



FIG. 47 



WO 91/11871 



HANDLE 
TRANSPORT 
TIMER 



-H42 



PCT/US91/00257 



46/48 

/ GENERATE 
^COUNTDOWN REQUEST, / 



1260 



DECREMENT Y_ 
TIMER COUNTS 



1262 



TIMER HAS, 
EXPIRED?. 



c 




1266 



MARK TRANSPORT^ 



TIMER INACTIVE 



r 



1268 



/ FORMAT ^\ 

y TIMEOUT MESSAGE^ 



XL 



1270 



UPDATE TIMEOUT 
MESSAGE WITH ADDRESS- 
OF TIMED MESSAGE 



c 



1272 



UPDATE TIMEOUT 
MESSAGE WITH 
TRANSPORT INDEX. 



I 



1274 



SEND TIMEOUT 
MESSAGE TO 
TRANSPORT STAGE 



FIG. 48 



WO 91/11871 



PCT/US91/00257 



47 / 4 8 



HAN OLE. 
SESSION 
TIMER 



-H43 



c 



GENERATE 
COUNTDOWN REQUEST 



c 




1230 



DECREMENT 
TIMER COUNT 



TIMER HAS, 
EXPIRED? 





1282 



1286 



f MARK SESSION *\ 
yTIMER INACTIVE^ / 



1288 



FORMAT 
MEOUT MESSAGE 



1290 



UPDATE TIMEOUT 
MESSAGE WITH SESSION 
INDEX 



I 



1292 



UPDATE TIMEOUT 
MESSAGE WITH PACKET] 
ID NUMBER 



1294 



SEND TIMEOUT 

MESSAGE TO 
SESSION STAGE 



( E * ,T ) 



FIG. 49 



WO 91/11871 



48/4 8^ 



PCT/US91/00257 



HANDLE 
DELETE TIMER 
REQUEST 



-.(3 



DELETION 
OF DATA LINK 
TIMER? 



DELETION OF 
TRANSPORT 
TIMER? 




RECEIVE DELETE 
MER REQUEST 

] ^1308 



1300 



MARK 




DATA LINK 




TIMER 




INACTIVE 


> 



TIMER 
AFFILIATED 
WITH TRANSPORT 
REQUEST? 

r-1326 



MARK TRANSPORT 
TIMER INACTIVE 



1306 



DELETION 
OF SESSION 
TIMER? 



1330 



YES 



MARK SESSION 
TIMER INACTIVE 



1332 



MARK 
TIMER TABLE 
ENTRY FREE 



L 



1328 



MARK TIMER 
TABLE ENTRY 
FREE 




NO 



ERROR 
HANDLING 



C 



EXIT 




1312 



MARK TRANSPORT 
TIMER ACTIVE 



I 



1314 



1318 



SET TRANSPORT 


TIMEOUT VALUE 




> 


f ^1316 




KICK 






TIMER 





MARK TIMER 
TABLE ENTRY 
FREE 



1320 




STORED MESSA6E 
SHOULD BE 
DELETED? 



YES 



RESTORE 
FOR LATER 
USE 



1322 



DELETE 
STORED 
MESSAGE 



FIG. 50 



